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(54) INFORMATION COMMUNICATION SYSTEM, INFORMATION COMMUNICATION METHOD, 

INFORMATION SIGNAL PROCESSING DEVICE AND INFORMATION SIGNAL PROCESSING 
METHOD, AND STORAGE MEDIUM 



(57) When a plurality of information signal process- 
ing apparatuses are connected via IEEE 1394 commu- 
nication control buses, these buses are connected via 
bridges, and bus reset occurs on a remote bus other 
than connected buses (step S1501), occurrence of re- 
mote bus reset is notified (steps S1502, S1505). Thus, 
even if bus reset occurs, the consistency of bus reset 
processing in an upper protocol layer can be ensured to 
realize normal data communication between buses. 
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Description 

Technical Field 

[0001] The present invention relates to an information 
signal processing apparatus connected to a communi- 
cation control network and an information signal 
processing method and, more particularly, to an infor- 
mation signal processing apparatus connected to an 
IEEE 1 394-compIiant communication control bus and 
an information signal processing method. 
[0002] Moreover, the present invention relates to an 
information communication system having a first com- 
munication control network, a second communication 
network different from the first communication control 
network, and a connection device for enabling commu- 
nication between the first communication control net- 
work and the second communication network, and an 
information communication method and, more particu- 
larly, to an information communication system connect- 
ed by, e.g., an IEEE 1394 serial interface, and an infor- 
mation communication method. 

Background Art 

[0003] A serial bus interface such as an IEEE 1394 
interface can simultaneously connect a plurality of de- 
vices such as a DV (Digital Video), DC (Digital Camera), 
host computer, scanner, and VTR, unlike a so-called 
Centronics parallel interface for one-to-one connection 
between a host computer and a terminal (device). This 
serial bus interface can realize a data communication 
network system or home network constructed by con- 
necting a plurality of devices based on an IEEE 1394 
standard as one of serial bus standards. 
[0004] Various devices are connected to these net- 
works, and many unspecified devices of different man- 
ufacturers may be connected. 

[0005] According to IEEE 1394-1995, a maximum of 
63 nodes can be connected to one 1394 bus (to be re- 
ferred to as a "local bus" hereinafter) by an IEEE 1394 
serial bus address designation method. If a 10-bit ad- 
dress space is defined for designation of a bus ID for 
specifying a bus, 1 ,023 buses can be connected to each 
other. In a cable environment, a cable between informa- 
tion signal processing apparatuses (to be referred to as 
"nodes" hereinafter) serving as devices is 4.5 m long at 
maximum. 

[0006] To solve technical limitations posed when 
more than a connectable maximum of 63 devices are to 
be connected via an IEEE 1 394 bus or a plurality of I EEE 
1394 buses located at remote places are to be connect- 
ed to each other, a device called a "1394 bridge" is gen- 
erally used. By connecting a plurality of IEEE 1 394 local 
buses via 1 394 bridges, devices connected to the dif- 
ferent local buses can communicate data. 
[0007] In IEEE 1394, when the bus configuration 
changes by, e.g., an increase/decrease in the number 



of nodes upon insertion/removal of a device node, ON/ 
OFF operation of the power supply, activation by hard- 
ware detection owing to a network error, or a direct in- 
struction under host control from a protocol, a new net- 

5 work configuration must be recognized. In this case, 
each node which has detected the change transmits a 
bus reset signal to execute a mode in which a new net- 
work configuration is recognized. 
[0008] This bus reset signal is transmitted to another 

to nodes on the local bus. After all the nodes detect the 
bus reset signal, bus reset starts. When bus reset starts, 
data transfer is temporarily suspended. After the bus re- 
set is finished, the suspended data transfer is restarted 
in a new network configuration. 

15 [0009] In a device connected to an IEEE 1 394 bus, a 
physical layer and data link layer in a transfer protocol 
are defined by IEEE 1 394. As for the upper layer, various 
upper protocols are defined and implemented in accord- 
ance with the intended use and application of a device. 

20 [0010] The upper protocols of IEEE 1394 determine 
a connection establishment method in communicating 
data with a specific device using an IEEE 1394 bus, a 
resource management method, an application data 
transmission/reception method, a connection cancella- 

25 tion method at the end of data transfer, a resume method 
in bus reset which is a feature of IEEE 1394 in addition 
to resume from an error, and protocols before and after 
bus reset. 

[0011] A DPP (Direct Print Protocol) as an example 
30 of the upper protocols defines that when bus reset oc- 
curs, a device which establishes a connection at the 
start of data transfer issues a reset command, and the 
other device returns an acknowledge upon reception of 
the command, thereby restarting data transfer. 
35 [0012] An AV/C protocol defines that when bus reset 
occurs before a node which has received an AV/C com- 
mand issued by the other node sends a response, the 
command itself becomes invalid, and the command is- 
suing node cannot expect any response. 
40 [001 3] In this manner, when IEEE 1 394 bus reset oc- 
curs, data transfer is temporarily suspended, and the 
network topology changes before and after bus reset. 
An upper protocol layer must cope with such a status 
change, so that the protocol standard defines proce- 
ss dures on both the data transmitting and receiving sides 
upon occurrence of bus reset. This definition allows con- 
tinuing data transfer between devices which implement 
the same upper protocol without any influence because, 
if bus reset occurs, the data transmitting and receiving 
so sides execute the defined appropriate processes in data 
transfer. 

[0014] However, if bus reset occurs on one local bus 
connected to another IEEE 1394 bus, the IEEE 1394 
bridge does not transfer the bus reset signal to the other 
55 local bus (to be referred to as a "remote bus" hereinaf- 
ter), i.e., does not propagate bus reset between the 
busses. Therefore, an error may occur in data transfer 
between nodes via the bridge. 
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[0015] When data is transferred between devices on 
the same local bus using the above-mentioned upper 
protocols, bus reset is transmitted to all the nodes on 
the local bus. Accordingly, both the data transmission 
and reception nodes can detect bus reset, and can ap- 5 
propriately execute bus reset procedures by the upper 
protocols. 

[0016] However, if bus reset occurs on one local bus 
during data transfer from a data transmission node on 
the local bus to a data reception node connected to the *o 
other local bus via an IEEE 1 394 bridge, the IEEE 1 394 
bridge does not propagate bus reset to the other bus. 
Therefore, the node connected to the remote bus cannot 
detect the bus reset, only the device connected to the 
local bus executes a bus reset procedure by the upper *5 
protocol layer, and the processes between the data 
transmitting and receiving sides are inconsistent. 

Disclosure of Invention 

20 

[0017] It is an object of the present invention to pro- 
vide a communication network system capable of per- 
forming normal data communication between commu- 
nication control networks while maintaining the consist- 
ency of network configuration update request process- 25 
ing in an upper protocol layer in a system constituted by 
connecting a plurality of communication control net- 
works (e.g., IEEE 1394 buses) via a connection device 
(e.g., IEEE 1394 bridge). 

[0018] It is another object of the present invention to 30 
provide a communication network system capable of 
performing normal data communication between buses 
while maintaining the consistency of bus reset process- 
ing in an upper protocol layer in a system constituted by 
connecting a plurality of communication control net- 35 
works (e.g., IEEE 1394 buses) via a connection device 
(e.g., IEEE 1394 bridge). 

[0019] Other features and advantages of the present 
invention will be apparent from the following description 
taken in conjunction with the accompanying drawings, *o 
in which like reference characters designate the same 
or similar parts throughout the figures thereof. 

Brief Description of Drawings 

45 

[0020] 

Fig. 1 is a block diagram showing the schematic 
configuration of the first embodiment according to 
the present invention; 50 
Fig. 2 is a view showing an example of a 1394 net- 
work configuration in the first embodiment; 
Fig. 3 is a block diagram for explaining the architec- 
ture of an IEEE 1394 standard in the first embodi- 
ment; 55 
Fig. 4 is a view showing services which can be pro- 
vided by a link layer in the first embodiment; 
Fig. 5 is a view showing services which can be pro- 



vided by a transaction layer in the first embodiment; 
Fig. 6 is a view for explaining the address space of 
a 1394 serial bus in the first embodiment; 
Fig. 7 is a view showing an example of the address 
and function of information stored in a CSR core 
register in the first embodiment; 
Fig. 8 is a view showing an example of the address 
and function of information stored in a serial bus 
register in the first embodiment; 
Fig. 9 is a view showing a structure of a configura- 
tion ROM of the minimum format in the first embod- 
iment; 

Fig. 10 is a view showing a structure of a configu- 
ration ROM of the general format in the first embod- 
iment; 

Fig. 1 1 is a view showing an example of the address 
and function of information stored in the serial bus 
register of a unit space in the first embodiment; 
Fig. 12 is a sectional view showing a 1394 serial 
bus cable in the first embodiment; 
Fig. 13 is a view showing a DS-link coding scheme 
in the first embodiment; 

Fig. 14 is a view for explaining a state after activa- 
tion of bus reset in the 1 394 network in the first em- 
bodiment; 

Fig. 15 is a flow chart showing processing from the 
start of bus reset to assignment of a node ID in the 
first embodiment; 

Fig. 1 6 is a flow chart showing details of parent-child 
relationship declaration processing in step S1502 
shown in Fig. 15; 

Fig. 17 is a flow chart showing details of node ID 
setting processing in step S1505 shown in Fig. 15; 
Fig. 1 8 is a view showing a format of a self ID packet 
in the first embodiment; 

Figs. 19A and 19B are views for explaining arbitra- 
tion in the 1394 network in the first embodiment; 
Fig. 20 is a view for explaining a case wherein asyn- 
chronous and isochronous transfer modes are 
mixed in one communication cycle in the first em- 
bodiment; 

Fig. 21 is a view showing the format of a communi- 
cation packet transferred based on the isochronous 
transfer mode in the first embodiment; 
Fig. 22 is a view showing the format of a communi- 
cation packet based on the asynchronous transfer 
mode in the first embodiment; 
Fig. 23 is a block diagram showing the arrangement 
of the 1394 interface block of a 1394 node in the 
first embodiment; 

Fig. 24 is a view showing the format of storage data 

in the configuration ROM in the first embodiment; 

Fig. 25 is a view showing the address space of the 

1394 node in the first embodiment; 

Fig. 26 is a view showing the serial bus register area 

of the 1394 node in the first embodiment; 

Fig. 27 is a view showing the 

REMOTE_BUS_RESET register of the 1394 node 
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in the first embodiment; 

Fig. 28 is a view showing communication control 
procedures complying with a DPP protocol in the 
first embodiment; 

Fig. 29 is a view showing communication control 5 
procedures complying with an AV/C protocol in the 
first embodiment; 

Fig. 30 is a view showing the serial bus register area 
of a 1394 node in the second embodiment accord- 
ing to the present invention; *o 
Fig. 31 is a view showing details of the 
NOTIFY_BUS_RESET register of the 1394 node in 
the second embodiment; 

Fig. 32 is a block diagram showing the detailed ar- 
rangement of a 1 394 bridge in the second embod- is 
iment; 

Fig. 33 is a view showing communication control 
procedures complying with a DPP protocol in the 
second embodiment; 

Fig. 34 is a view showing communication control 20 
procedures complying with an AV/C protocol in the 
second embodiment; 

Fig. 35 is a view showing communication control 
procedures complying with a DPP protocol in the 
third embodiment according to the present inven- 25 
tion; 

Fig. 36 is a block diagram showing the configuration 
of the fourth embodiment according to the present 
invention; 

Fig. 37 is a view showing communication control 30 
procedures complying with a DPP protocol in the 
fourth embodiment; 

Fig. 38 is a view showing communication contra! 
procedures complying with an AV/C protocol in the 
fourth embodiment; 35 
Fig. 39 is a view showing the serial bus register area 
of a 1394 node in the fifth embodiment according to 
the present invention; 

Fig. 40 is a view showing communication control 
procedures complying with a DPP protocol in the 40 
fifth embodiment; and 

Fig. 41 is a view showing communication control 
procedures complying with an AV/C protocol in the 
fifth embodiment. 

45 

Best Mode for Carrying Out the Invention 

[0021] Preferred embodiments of present invention 
will be described in detail below with reference to the 
accompanying drawings. so 

[First Embodiment] 

[0022] Fig. 1 is a block diagram showing the schemat- 
ic configuration of the first embodiment according to the 55 
present invention. The first embodiment is constituted 
by two IEEE 1394-compliant local buses A 102 and B 
103, and a 1394 bridge 101 for connecting them. Fig. 1 



shows two local buses, but a larger number of local bus- 
es can be connected via 1394 bridge devices. 
[0023] Each local bus has a bus ID as bus specifying 
information for specifying each local bus. The local bus 
A 102 represented by a bus ID "3FDh" and the local bus 
B 103 represented by a bus ID "3FEh" are connected to 
a plurality of device nodes. 

[0024] In the first embodiment shown in Fig. 1 , a node 
A1 (104) connected to the local bus A 102 is a digital 
still camera, and a node A2 (105) is a digital video cam 
coder. A node B1 (106) connected to the local bus B 103 
is a printer, and a node B2 (107) is a digital video cam 
coder. 

[0025] The node A1 (104) implements a direct print 
protocol standardized in advance as an upper protocol, 
whereas the node A2 (105) implements a standardized 
AV/C protocol. 

[0026] Similarly, the node B1 (106) connected to the 
local bus B 103 implements a direct print protocol as an 
upper protocol, whereas the node B2 (107) implements 
an AV/C protocol. 

<Technical Overview of IEEE 1394 Standard> 

[0027] The technique of the IEEE 1 394-1 995 stand- 
ard applied to the digital interface shown in Fig. 1 of the 
first embodiment will be explained. Details of the IEEE 
1 394-1 995 standard (to be referred to as the "IEEE 1 394 
standard" hereinafter) are described in "IEEE Standard 
for a High Performance Serial Bus" published by IEEE 
(The Instituted of Electrical and Electronics Engineers, 
Inc.), August 30, 1996. 

(1) Overview 

[0028] Fig. 2 shows an example of a communication 
system (to be referred to as a "1394 network") consti- 
tuted by nodes having digital interfaces complying with 
the IEEE 1394 standard (to be referred to as "1394 in- 
terfaces"). The 1 394 network constitutes a bus type net- 
work capable of communicating serial data. 
[0029] In Fig. 2, nodes A to H are connected via an 
IEEE 1394 standard-compliant communication cable. 
These nodes A to H are electronic devices such as a 
PC (Personal Computer), digital VTR (Video Tape Re- 
corder), DVD (Digital Video Disc) player, digital camera, 
hard disk drive, and monitor. 

[0030] The connection method of the 1 394 network 
may include both a daisy chain method and node branch 
method, and enables connection with a high degree of 
flexibility. 

[0031] The 1394 network automatically performs bus 
reset when, e.g., an existing device is removed, a new 
device is added, or an existing device is turned on/off. 
By performing this bus reset, the 1394 network can au- 
tomatically recognize a new configuration and assign ID 
information to each device. This function allows the 
1394 network to always recognize the network configu- 
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ration. 

[0032] The 1 394 network also has a function of relay- 
ing data transferred from another device. This function 
allows alt the devices to grasp the operation status of 
the bus. 5 
[0033] The 1 394 network has a function called plug & 
play. This function allows the 1 394 network to automat- 
ically recognize connected devices by only connecting 
them without turning off all the devices. 
[0034] The 1394 network copes with data transfer 1Q 
speeds of 100/200/400 Mbps. A device having a higher 
data transfer speed can support a lower data transfer 
speed, so that devices having different data transfer 
speeds can be connected. 

[0035] The 1394 network further copes with two dif- *5 
ferent data transfer schemes (i.e., asynchronous and is- 
ochronous transfer modes). 

[0036] The asynchronous transfer mode is effective 
in transferring data (i.e., a control signal and file data) 
which should be asynchronously transferred if neces- 20 
sary. The isochronous transfer mode is effective in 
transferring data (i.e., video data and audio data) which 
should be successively transferred by a predetermined 
amount at a constant data transfer speed. 
[0037] The asynchronous and isochronous transfer 25 
modes can be mixed in each communication cycle (one 
cycle is generally 125 u,S). Each transfer mode is exe- 
cuted after transfer of a cycle start packet (to be referred 
to as a "CSP") representing the start of the cycle. 
[0038] In each communication cycle period, the iso- 30 
chronous transfer mode has higher priority than that of 
the asynchronous transfer mode. The transfer band of 
the isochronous transfer mode is ensured in each com- 
munication cycle. 

35 

(2) Architecture 

[0039] The architecture of the IEEE 1394 standard will 
be described with reference to Fig. 3. Fig. 3 is a block 
diagram showing the architecture of the IEEE 1394 40 
standard in the first embodiment. 
[0040] The building elements of the IEEE 1 394 inter- 
face will be explained. The IEEE 1394 interface is func- 
tionally made up of a plurality of layers (hierarchies). In 
Fig. 3, the IEEE 1394 interface is connected to the IEEE 45 
1394 interface of another node via an IEEE 1394 stand- 
ard-compliant communication cable 301. The IEEE 
1394 interface has one or more communication ports 
302, and each communication port 302 is connected to 
a physical layer 303 included in hardware. so 
[0041] In Fig. 3, the hardware is comprised of the 
physical layer 303 and a link layer 304. The physical lay- 
er 303 performs a physical and electrical interface with 
another node, detection of bus reset and its processing, 
encoding/decoding of input and output signals, and ar- 55 
bitration of bus access. The link layer 304 performs gen- 
eration and transmission/reception of a communication 
packet, and control of the cycle timer. 



[0042] In Fig. 3, the firmware includes a transaction 
layer 305 and serial bus management 306. The trans- 
action layer 305 manages the asynchronous transfer 
mode, and provides various transactions (read, write, 
and lock). The serial bus management 306 provides a 
function of controlling the self node, managing the con- 
nection state of the self node, managing the ID informa- 
tion of the self node, and managing the resource of the 
serial bus network on the basis of a CSR architecture 
(to be described later). 

[0043] The hardware 303 and 304 and the firmware 
305 and 306 substantially constitute a 1394 interface. 
The basic configuration is defined by the IEEE 1394 
standard. 

[0044] An application layer 307 included in the soft- 
ware changes depending on application software to be 
used, and controls how to communicate data on the net- 
work. For example, for moving picture data of a digital 
VTR, the application layer 307 is defined by a commu- 
nication protocol such as an AV/C protocol. 

(2-1) Function of Link Layer 304 

[0045] Fig. 4 is a view showing services which can be 
provided by the link layer 304. In Fig. 4, the link layer 
304 provides the following four services: 

©Link request (LK_DATA. request) for requesting 
transfer of a predetermined packet of a response 
node 

(D-ink indication (LK_DATA. indication) for indicat- 
ing reception of a predetermined packet to a re- 
sponse node 

©Link response (LK_ DATA, response) representing 
reception of an acknowledge from a response node 
® Link confirmation (LK_DATA. confirmation) for 
confirming an acknowledge from a request node 
Note that the link response (LK_DATA.response) 
does not exist in broadcast communication and the 
transfer of an isochronous packet. 

[0046] Based on these services, the link layer 304 re- 
alizes the two transfer schemes, i.e., asynchronous and 
isochronous transfer modes. 

(2-2) Function of Transaction Layer 305 

[0047] Fig. 5 is a view showing services which can be 
provided by the transaction layer 305. In Fig. 5, the 
transaction layer 305 provides the following four servic- 
es: 

©Transaction request (TR_DATA. request) for re- 
questing a predetermined transaction of a response 
node 

©Transaction indication (TR_DATA.indication) for 
indicating reception of a predetermined transaction 
request to a response node 
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©Transaction response (TR_DATA.response) rep- 
resenting reception of state information (including 
data for write and lock) from a response node 
©Transaction confirmation (TR_DATA.conftrma- 
tion) for confirming state information from a request 
node 

[0048] Based on these services, the transaction layer 
305 manages asynchronous transfer, and realizes the 
following three transactions: 

©Read transaction 
©Write transaction 
©Lock transaction 

[0049] In ©read transaction, a request node reads in- 
formation stored at a specific address of a response 
node. 

[0050] In ©write transaction, the request node writes 
predetermined information at a specific address of the 
response node. 

[0051] In ©lock transaction, the request node trans- 
fers reference data and update data to the response 
node, compares information at a specific address of the 
response node with the reference data, and updates the 
information at the specific address to the update data in 
accordance with the comparison result. 

(2-3) Function of Serial Bus Management 306 

[0052] The serial bus management 306 can provide 
the following three functions, i.e., ©node control, ©is- 
ochronous resource manager (to be referred to as an 
"IRM"), and ©bus manager. 

[0053] ©Node control provides a function of manag- 
ing the above-described layers, and managing asyn- 
chronous transfer executed with another node. 
[0054] ©The IRM provides a function of managing is- 
ochronous transfer executed with another node. More 
specifically, the IRM manages pieces of information 
necessary to assign a transfer bandwidth and a channel 
number, and provides these pieces of information to an- 
other node. 

[0055] The IRM exists only on a local bus, and is dy- 
namically selected from other candidates (nodes having 
the IRM function) every bus reset. The IRM may provide 
some of functions (connection configuration manage- 
ment, power supply management, speed information 
management, and the like) which can be provided by 
the bus manager (to be described below). 
[0056] ©The bus manager has the IRM function, and 
provides a more advanced bus management function 
than the IRM. 

[0057] More specifically, the bus manager has a func- 
tion of performing more advanced power supply man- 
agement (manage, for each node, information repre- 
senting whether power can be supplied via a communi- 
cation cable and whether power must be supplied), 



more advanced speed information management (man- 
age the maximum transfer speed between nodes), more 
advanced connection configuration management (cre- 
ate a topology map), and bus optimization based on 

5 these pieces of management information, and providing 
the pieces of information to another node. 
[0058] The bus manager can provide an application 
with a service for controlling a serial bus network. This 
service includes a serial bus control request 

10 (SB_CONTROL.request), serial bus event control con- 
firmation (SB_CONTROL.confirmation), and serial bus 
event indication (SB_CONTROLindication). 
[0059] The serial bus control request 
(SB_CONTROLrequest) is a service of requesting bus 

15 reset by an application. 

[0060] The serial bus event control confirmation 
(SB_CONTROL.confirmation) is a service of confirming 
the serial bus control request (SB_CONTROL.request) 
for the application. The serial bus event indication 

20 (SB_CONTROL.indication) is a service of indicating an 
asynchronously generated event to the application. 

(3) Description of Addressing 

25 [0061] Fig. 6 is a view for explaining an address space 
in the 1 394 interface. The 1 394 interface defines a 64-bit 
address space in accordance with a CSR (Command 
and Status Register) architecture complying with ISO/ 
IEC 13213:1994. 

30 [0062] In Fig. 6, a 10-bit field 601 is used for an ID 
numberfor designating a predetermined bus, and a 6-bit 
field 602 is used for an ID number for designating a pre- 
determined device (node). The upper 16 bits will be 
called a "node ID", and each node identifies another 

35 node using this node ID. Each node can also perform 
communication with an identified partner using this node 
ID. 

[0063] The remaining 48-bit field designates an ad- 
dress space (256-Mbyte structure) of each node. Of this 
40 field, a 20-bit field 603 designates a plurality of areas 
constituting an address space. 
[0064] In the field 603, an area "0 - OxFFFFD" is called 
a memory space. 

[0065] An area "OxFFFFE" is called a private space, 
45 and represents addresses freely usable by each node. 
The area "OxFFFFE" is called a register space, and 
stores information common to nodes connected to a 
bus. Each node can use information of the register 
space to manage communication between nodes. 
so [0066] A 28-bit field 604 designates an address where 
information common or unique to each node is stored. 
[0067] For example, the first 512 bytes in the register 
space are used for a CSR architecture core (CSR core) 
register. Fig. 7 shows the address and function of infor- 
55 mation stored in the CSR core register. The offset in Fig. 
7 is a relative position from "OxFFFFFOOOOOOO". 
[0068] The next 512 bytes in Fig. 6 are used for a se- 
rial bus register. Fig. 8 shows the address and function 
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of information stored in the serial bus register. The offset 
in Fig. 8 is a relative position from "OxFFFFF0000200 n . 
[0069] The next 1,024 bytes in Fig. 6 are used for a 
configuration ROM. The configuration ROM has mini- 
mum and general formats, and is arranged from 5 
M OxFFFFF0000400". Fig. 9 shows a configuration ROM 
of the minimum format. In Fig. 9, a vender ID is a 24-bit 
numerical value uniquely assigned to each vendor by 
IEEE. 

[0070] Fig. 1 0 shows a configuration ROM of the gen- 10 
eral format. In Fig. 10, the vendor ID is stored in a root 
directory 1002. A bus inform block 1001 and root leaf 
1005 can hold node unique IDs as unique ID information 
for identifying each node. 

[0071] The node unique ID determines a unique ID *5 
capable of specifying one node regardless of the man- 
ufacturer and model. The node unique ID is made up of 
64 bits. The upper 24 bits represent a vendor ID, and 
the lower 48 bits represent information (e.g., the manu- 
facturing number of a node) freely settable by the man- 20 
ufacturer of each node. The node unique ID is used 
when, for example, a specific node is kept recognized 
before and after bus reset. 

[0072] In Fig. 10 showing the configuration ROM of 
the general format, the root directory 1002 can hold in- 25 
formation about the basic function of a node. Detailed 
functional information is stored in subdirectories (unit di- 
rectories 1004) offset from the root directory 1002, The 
unit directories 1004 store, e.g., information about soft- 
ware units supported by a node. More specifically, the 30 
unit directories 1004 hold information about a data 
transfer protocol for data communication between 
nodes, and a command set for defining predetermined 
communication procedures. 

[0073] In Fig. 10, a node dependent info directory 35 
1003 can hold information unique to a device. The node 
dependent info directory 1003 is offset from the root di- 
rectory 1002. 

[0074] In Fig. 10, vendor dependent information 1006 
can hold information unique to a vendor which manu- *o 
factures or sells nodes. 

[0075] The remaining area is called a unit space, and 
designates an address where information unique to 
each node, e.g., identification information (manufactur- 
er name, model name, or the like) or use conditions of 45 
each device are stored. Fig. 11 shows the address and 
function of information stored in the serial bus register 
of the unit space. The offset in Fig. 11 is a relative posi- 
tion from n 0xFFFFF0000800". 

[0076] In general, to simplify the design of different so 
types of bus systems, each node should use only the 
first 2,048 bytes of the register space. In other words, 
the bus system is desirably constituted by 4,096 bytes 
as a total of the CSR core register, the serial bus register, 
the configuration ROM, and the first 2,048 bytes of the 55 
unit space. 



(4) Structure of Communication Cable 

[0077] Fig. 12 is a sectional view showing an IEEE 
1394-compliant communication cable. 
[0078] The communication cable is made up of two 
twisted-pair signal lines and a power supply line. This 
power supply line can supply power even to a device 
whose main power supply is turned off, or a device 
which decreases in power due to a failure. The power 
supply voltage flowing through the power supply line is 
defined as 8 to 40 V, and the current is defined as a 
maximum of DC 1 .5 A. 

[0079] The two twisted-pair signal lines transmit infor- 
mation signals encoded by a DS-link (Data/Strobe link) 
coding scheme. Fig. 13 is a view for explaining the DS- 
link coding scheme in the first embodiment. 
[0080] The DS-link coding scheme shown in Fig. 13 
is suitable for high-speed serial data communication, 
and requires two twisted-pair lines. One twisted-pair line 
transmits a data signal, whereas the other twisted-pair 
line transmits a strobe signal. The receiving side can re- 
generate a clock by exclusive-ORing the data and 
strobe signals received from the two signal lines. 
[0081] The 1394 interface using the DS-link coding 
scheme attains the following advantages: 

©The transfer efficiency is higher than other coding 
schemes. 

©The PLL circuit can be omitted to downsize the 
controller LSI. 

©Information representing an idle state need not 
be transmitted, so that the transceiver circuit can 
easily change to a sleep state to reduce the power 
consumption. 

(5) Bus Reset Function 

[0082] The 1 394 interface of each node can automat- 
ically detect a change in network connection configura- 
tion. In this case, the 1394 network executes processing 
called bus reset by the following procedures. A change 
in connection configuration can be detected by a change 
in bias voltage applied to the communication port of 
each node. 

[0083] A node which has detected a change in net- 
work connection configuration (e.g., an increase/de- 
crease in the number of nodes upon insertion/removal 
of a node or ON/OFF operation of a node), or a node 
which must recognize a new connection configuration 
transmits a bus reset signal onto the bus via the 1394 
interface. 

[0084] The 1394 interface of a node which has re- 
ceived the bus reset signal transmits occurrence of bus 
reset to its link layer 304, and transfers the bus reset 
signal to another node. A node which has received the 
bus reset signal clears the recognized network connec- 
tion configuration and the node ID assigned to each de- 
vice. After all the nodes detect the bus reset signal, each 
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node automatically performs initialization processing 
(recognition of a new connection configuration and as- 
signment of a new node ID) accompanying bus reset. 
[0085] Note that bus reset can be activated not only 
by a change in connection configuration described 5 
above, but also by directly issuing an instruction from 
the application layer 307 to the physical layer 303 under 
host control. 

[0086] After bus reset occurs, data transfer is tempo- 
rarily suspended, and then restarted in a new network 10 
after completion of initialization processing accompany- 
ing bus reset. 

(6) Description of Sequence After Occurrence of Bus 
Reset 15 

[0087] After bus reset occurs, the 1394 interface of 
each node automatically executes recognition of a new 
connection configuration and assignment of a new node 
ID. A basic sequence from the start of bus reset to as- 20 
signment processing of a node ID will be explained with 
reference to Figs. 14 to 16. 

[0088] Fig. 14 is a view for explaining a state after oc- 
currence of bus reset in the 1394 network of Fig. 2. 
[0089] In Fig. 14, node A comprises one communica- 25 
tion port; node B, two communication ports; node C, two 
communication ports; node D, three communication 
ports; node E, one communication port; and node F, one 
communication port. The communication port of each 
node has a port number for identifying each port. 30 
[0090] Processing from the start of bus reset to as- 
signment of a node ID in Fig. 14 will be explained with 
reference to the flow chart of Fig. 15. Fig. 15 is a flow 
chart showing processing from the start of bus reset to 
assignment of a node ID in the first embodiment. 35 
[0091] Nodes A to F shown in Fig. 14 that constitute 
a 1394 network always monitor whether bus reset oc- 
curs, as shown in step S1501 . If a node which has de- 
tected a change in connection configuration outputs a 
bus reset signal, each node detects bus reset to execute *o 
processing from step S1502. 

[0092] If bus reset is detected, the flow advances from 
step S1501 to step S1502, and respective nodes de- 
clare parent-child relationships between their communi- 
cation ports after occurrence of bus reset. In step 45 
S1503, whether parent-child relationships between ali 
the nodes are determined is checked. If NO in step 
S1503, the flow returns to step S1502, and each node 
repeats processing in step S1502 until parent-child re- 
lationships between all the nodes are determined. so 
[0093] After parent-child relationships between all the 
nodes are determined, the flow shifts from step S1503 
-to step S1 504. In step S1 504, the 1394 network deter- 
mines a node, i.e., root which performs network arbitra- 
tion. After the root is determined, the flow shifts to step 55 
S1505, and the 1394 interface of each node executes 
an operation of automatically setting the self node ID. In 
step S1506, whether node IDs have been set for all the 



nodes to complete ID setting processing is checked. If 
NO in step S1506, the flow returns to step S1505, and 
each node sets an ID for the next node based on pre- 
determined procedures. 

[0094] After node IDs are set for all the nodes, the flow 
advances from step S1506 to step S1507, and each 
node executes isochronous transfer or asynchronous 
transfer. After data transfer ends, the 1 394 interface of 
each node returns to step S1501 to monitor bus reset. 
[0095] By the above procedures, the 1394 interface 
of each node can automatically execute recognition of 
a new connection configuration and assignment of a 
new node ID every time bus reset occurs. 

(7) Determination of Parent-Child Relationship 

[0096] Details of parent-child relationship declaration 
processing (i.e., processing of recognizing parent-child 
relationships between nodes) in step S1502 shown in 
Fig. 1 5 will be described with reference to the flow chart 
of Fig. 16. Fig. 16 is a flow chart showing details of par- 
ent-child relationship declaration processing in step 
S1502 shown in Fig. 15 in the first embodiment. 
[0097] In parent-child relationship declaration 
processing of the first embodiment, nodes A to F on the 
1 394 network confirm the connection states (connection 
or disconnection) of the self communication ports upon 
occurrence of bus reset in step S1 601 shown in Fig. 16. 
After confirming the connection state of the communi- 
cation port, each node counts in step S 1602 the number 
of communication ports (to be referred to as connected 
ports) connected to other nodes, and checks whether 
the number of connected ports is one. 
[0098] If the number of connected ports is one in step 
S1602, the flow shifts to step S1603, and the node rec- 
ognizes itself as a "leaf. The "leaf means a node con- 
nected to only one node. In step S1604, the node serv- 
ing as a leaf declares a "child" to a node connected to 
the connected port. At this time, the leaf recognizes that 
the connected port is a "parent port (communication port 
connected to a parent node)". After that, the flow ad- 
vances to step S1611. 

[0099] Parent-child relationships are sequentially de- 
clared between a branch and a leaf serving as a network 
terminal end, and then between branches. The parent- 
child relationships between nodes are determined in the 
order of a communication port which can make a dec- 
laration early. A communication port which declares a 
child is recognized as a "parent port" between nodes, 
and a communication port which has received the dec- 
laration is recognized as a "child port (communication 
port connected to a child node)". For example, in Fig. 
14, nodes A, E, and F recognize themselves as leaves, 
and declare child-parent relationships. Then, nodes A 
and B are determined to be a child and parent; nodes E 
and D, a child and parent; and nodes F and D, a child 
and parent. 

[01 00] If the number of connected ports is not one but 
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two or more as a result of processing in step S 1 602, the 
flow shifts to step S1 605, and the node recognizes itself 
as a "branch". The "branch" means a node connected 
to two or more nodes. In step S1606, the node serving 
as a branch receives declaration of a parent-child rela- 5 
tionship from a node at each connected port. The con- 
nected port which has received the declaration is rec- 
ognized as a "child port". 

[0101] After one connected port is recognized as a 
"child port", the flow advances to step S1607, and the 10 
branch detects whether there are two or more connect- 
ed ports (i.e., undefined ports) for which parent-child re- 
lationships have not been determined yet. If YES in step 

51 607, the flow returns to processing in step S1 606, and 
the branch receives declaration of a parent-child rela- 15 
tionship from a node at each connected port again. 
[0102] If NO in step S1607, the flow shifts to step 

51608, and the branch checks whether only one unde- 
fined port exists. If YES in step S1608, the branch rec- 
ognizes the undefined port as a "parent port", and de- 20 
dares a "child" to a node connected to the port in step 

51609, Then, the flow advances to step S1611. 
[0103] The branch cannot declare a child to another 
node until the number of remaining undefined ports de- 
creases to one. For example, in the configuration of Fig. 25 
14, nodes B, C, and D recognize themselves as branch- 
es, 'and receive declarations from leaves or other 
branches. Node D declares a parent-child relationship 

to node C after parent-child relationships between D and 
E and between D and F are determined. Node C which 30 
has received the declaration from node D declares a 
parent-child relationship to node B. 
[0104] If NO in step S1608 (i.e., all the connected 
ports of the branch are parent ports), the flow shifts to 
step S1610, and the branch recognizes itself as a root. 35 
For example, in Fig. 14, node B in which all the connect- 
ed ports are parent ports is recognized by other nodes 
to be a root for arbitrating communication on the 1394 
network. 

[01 05] In this case, node B is determined to be a root. 4 ® 
If the timing at which node B declares a parent-child re- 
lationship is earlier than the timing at which node C de- 
clares a parent-child relationship, another node may be- 
come a root. Hence, even the same network configura- 
tion does not always use the same node as a root. 45 
[0106] After the parent-child relationships of all the 
connected ports are declared, each node can recognize 
the connection configuration of the 1394 network as a 
hierarchical structure (tree structure). The declarations 
at all the connected ports end in step S1611, and the so 
flow returns to the main routine. Note that the parent 
node is an upper node in the hierarchical structure, and 
the child node is a lower node in the hierarchical struc- 
ture. 

55 

(8) Assignment of Node ID 

[0107] Node ID setting processing (i.e., processing of 



automatically assigning the node ID of each node) in 
step S1505 shown in Fig. 15 will be described in detail 
with reference to Fig. 17. Fig. 17 is a flow chart showing 
details of node ID setting processing in step S1505 of 
Fig. 15. The node ID is made up of a bus number and 
node number. In the first embodiment, respective nodes 
are connected to the same bus, and have the same bus 
number. 

[0108] In node ID setting processing of the first em- 
bodiment, the root gives node ID setting permission to 
a communication port having the smallest number 
among child ports connected to nodes whose node IDs 
have not been set yet. In Fig. 17, the root sets the node 
IDs of all the nodes connected to a child port having the 
smallest number, determines that the child port has 
been set, and performs the same control for a child port 
having the second smallest number. After the IDs of all 
the nodes connected to child ports are set, the root sets 
the self node ID. Node numbers contained in node IDs 
are basically sequentially assigned as 0, 1, 2,... to 
leaves and branches. Thus, the root has the largest 
node number. 

[01 09] A node which has received the setting permis- 
sion in step S1 701 checks in step S1 702 whether a child 
port including a node whose node ID has not been set 
yet exists in the self child ports. If NO in step S1 702, the 
flow shifts to step S1705. 

[0110] If YES in step S 1 702, the flow advances to step 
S1 703, and the node which has received setting permis- 
sion gives setting permission to a node directly connect- 
ed to the child port (child port having the smallest 
number). In step S1704, the node which has received 
setting permission checks whether a child port including 
a node whose node ID has not been set yet exists in the 
self child ports. If YES in step S1704, the flow returns 
to step S1703, and the node gives setting permission to 
a child port having the smallest number. 
[0111] If NO in step S1704, the flow shifts to step 
S1705. 

[0112] In this way, if a child port including an unset 
node is not detected in step S1702 or S1704, the flow 
shifts to step S1705, and the node which has received 
setting permission sets the self node ID. In step S1706, 
the node which has set the self node ID broadcasts a 
self ID packet containing information about its node 
number and the connection state of the communication 
port. "Broadcast" means to transfer a communication 
packet of a given node to many unspecified nodes con- 
stituting a 1394 network. 

[0113] Each node can receive this self ID packet to 
recognize a node number assigned to each node, and 
can recognize the assigned node number. For example, 
in Fig. 14, node B serving as a root gives node ID setting 
permission to node A connected to a communication 
port having the smallest port number "#1". Node A as- 
signs "No. 0" as its node number, and sets a node ID 
made up of a bus number and the node number. Then, 
node A broadcasts a self ID packet containing the node 
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number. 

[0114] Fig. 18 shows a format of a self ID packet out- 
put in step S1706. In Fig. 18, reference numeral 1801 
denotes a field for storing the node number of a node 
which has sent a self ID packet; 1802, a field for storing 
information about a compatible transfer speed; 1803, a 
field representing the presence/absence of a bus man- 
agement function (the presence/absence of a bus man- 
ager ability); and 1804, a field for storing information 
about power consumption and supply characteristics. 
[0115] In Fig. 18, reference numeral 1805 denotes a 
field for storing information about the connection state 
of a communication port having a port number "#0" (con- 
nection, disconnection, parent-child relationship of a 
communication port, and the like); 1806, a field for stor- 
ing information about the connection state of a commu- 
nication port having a port number "#1 " (connection, dis- 
connection, parent-child relationship of a communica- 
tion port, and the like); and 1807, a field for storing in- 
formation about the connection state of a communica- 
tion port having a port number "#2" (connection, discon- 
nection, parent-child relationship of a communication 
port, and the like). 

[01 1 6] When a node which sends a self ID packet has 
a bus manager ability, a contender bit in the field 1803 
is set to "1"; otherwise, to "0". 

[0117] The bus manager is a node having a function 
of performing, based on various pieces of information 
contained in the above-mentioned self ID packet, bus 
power supply management (manage, for each node, in- 
formation representing whether power can be supplied 
via a communication cable and whether power must be 
supplied), speed information management (manage the 
maximum transfer speed between nodes from informa- 
tion about a compatible transfer speed of each node), 
topology map information management (manage the 
network connection configuration from parent-child re- 
lationship information of a communication port), and bus 
optimization based on topology map information, and a 
function of providing these pieces of information to other 
nodes. These functions allow the node serving as a bus 
manager to manage the bus over the 1394 network. 
[01 1 8] In processing of Fig. 1 7, a node which has set 
a node ID after processing in step S1706 checks in step 

51707 whether a parent node exists. If YES in step 
S1707, the flow returns to step S1702, and the parent 
node executes processing from step S1702, and gives 
permission to a node whose node ID has not been set 
yet. 

[01 19] If NO in step S1 707, the node is determined to 
be a root. The flow shifts to step S1708, and the node 
serving as a root checks whether node IDs are set for 
nodes connected to all the child ports. If ID setting 
processing for all the nodes is not completed in step 

51 708 (NO), the flow returns to step S1 701 , and the root 
gives ID setting permission to a child port having the 
smallest number among child ports including the node. 
Then, processing after step S1702 is executed. 



[0120] If YES in step S1708, the flow shifts to step 

51709, and the root sets the self node ID. After setting 
the node ID, the root broadcasts a self ID packet in step 

51710. Then, the flow returns to the main routine. 

5 [0121] By this processing, the 1394 network can au- 
tomatically assign a node ID to each node. 
[01 22] If a plurality of nodes have a bus manager abil- 
ity after node ID setting processing, a node having the 
largest node number serves as a bus manager. That is, 
10 when a root having the largest node number in the net- 
work has a bus manager function, the root serves as a 
bus manager. 

[0123] If, however, the root does not have this func- 
tion, a node having the largest node number next to the 
root serves as a bus manager. Which node becomes a 
bus manager can be grasped by checking the contender 
bit 1803 in a self ID packet broadcasted by each node. 

(9) Arbitration Function 

[01 24] Figs. 1 9A and 1 9B are views for explaining ar- 
bitration in the 1394 network in the first embodiment 
shown in Fig. 1. 

[0125] The 1394 network always performs bus ac- 
cess arbitration prior to data transfer. The 1394 network 
is a logical bus type network, and can transfer the same 
communication packet to all the nodes in the network 
by relaying a communication packet transferred from 
each node to another node. To prevent collision of com- 
munication packets, arbitration must be executed, 
which allows only one node to transfer a packet at given 
time. 

[0126] Fig. 19A is a view for explaining a case wherein 
nodes B and F issue bus access requests. 
[0127] When arbitration starts, nodes B and F issue 
bus access requests to their parents. A parent (i.e., node 
C) which has received the request from node B relays 
the bus access request to its parent node (i.e., node D). 
This request is finally sent to a root (node D) which finally 
executes arbitration. 

[0128] The root which has received the bus access 
requests determines which node can use the bus. This 
arbitration operation can be done by only a node serving 
as a root, and a node which wins arbitration is permitted 
to use the bus. 

[0129] Fig. 19B is a view showing a case wherein a 
request from node F is permitted, and a request from 
node B is denied. 

[0130] The root transmits a DP (Data Prefix) packet 
to a node which loses in arbitration, and notifies the node 
of denial. The denied node holds a bus access request 
until the next arbitration. 

[0131] By controlling arbitration, the 1394 network 
can manage bus access. 

(10) Communication Cycle 

[01 32] In the first embodiment, the asynchronous and 
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isochronous transfer modes can be mixed in time divi- 
sion in each communication cycle period. In general, the 
communication cycle period is 125 u, S long. 
[0133] Fig. 20 is a view for explaining a case wherein 
the asynchronous and isochronous transfer modes are 
mixed in one communication cycle. 
[01 34] In the first embodiment, the isochronous trans- 
fer mode is executed preferentially to the asynchronous 
transfer mode. This is because an idle period (subaction 
gap) necessary for activating asynchronous transfer af- 
ter a cycle start packet is set longer than an idle period 
(isochronous gap) necessary for activating isochronous 
transfer. Thus, isochronous transfer is executed prefer- 
entially to asynchronous transfer. 
[0135] In Fig. 20, a cycle start packet (to be referred 
to as a "CSP" hereinafter) is transferred from a prede- 
termined node at the start of each communication cycle. 
Each node can count the same time as another node by 
adjusting the time using the CSP. 

(11) Isochronous Transfer Mode 

[0136] The isochronous transfer mode is an iso- 
chronous type transfer scheme. Isochronous mode 
transfer can be executed in a predetermined period after 
the start of a communication cycle. The isochronous 
transfer mode is always executed every cycle in order 
to maintain real-time transfer. 
[0137] The isochronous transfer mode is a transfer 
mode suitable for transfer of data such as moving pic- 
ture data or audio data which requires real-time transfer. 
The isochronous transfer mode is broadcasting commu- 
nication, unlike one-to-one communication in the asyn- 
chronous transfer mode. That is, a packet sent from a 
given node is transferred to all the nodes on the network. 
Note that isochronous transfer does not use any ack (ac- 
knowledge). 

[0138] In Fig. 20, channel e (ch e), channel s (ch s), 
and channel k (ch k) represent periods during which 
nodes perform isochronous transfer. The 1394 interface 
uses different channel numbers in order to discriminate 
a plurality of different isochronous transfer operations. 
This enables isochronous transfer between a plurality 
of nodes. In this case, the channel number does not 
specify a transmission destination, but only gives a log- 
ical number to data. 

[0139] The isochronous gap shown in Fig. 20 repre- 
sents a bus idle state. Upon the lapse of a predeter- 
mined time in this idle state, a node which desires iso- 
chronous transfer determines that it can use the bus, 
and executes arbitration. 

[0140] Fig. 21 shows the format of a communication 
packet transferred based on the isochronous transfer 
mode in the first embodiment. The communication pack- 
et transferred based on the isochronous transfer mode 
will be called an isochronous packet. 
[0141] In Fig. 21 , the isochronous packet is made up 
of a header 2101, header CRC 2102, data 2103, and 



data CRC 2104. 

[0142] The header 21 01 includes a field 21 05 for stor- 
ing the data length of the data 2103, a field 2106 for 
storing format information of the isochronous packet, a 
5 field 2107 for storing the channel number of the iso- 
chronous packet, a field 2108 for storing a packet format 
and a transaction code (tcode) for identifying processing 
which must be executed, and a field 2109 for storing an 
isochronous code. 

10 

(12) Asynchronous Transfer Mode 

[0143] The asynchronous transfer mode of the first 
embodiment is an asynchronous type transfer scheme. 

15 Asynchronous transfer is one-to-one communication 
from a self node to a partner node, and can be executed 
until the next communication cycle starts (i.e., the CSP 
of the next communication cycle is transferred) after the 
end of an isochronous transfer period. 

20 [0144] In Fig. 20, the first subaction gap represents a 
bus idle state. After the idle time reaches a predeter- 
mined value, a node which desires asynchronous trans- 
fer determines that it can use the bus, and executes ar- 
bitration. 

25 [0145] The node which gains bus access by arbitra- 
tion transfers a packet shown in Fig. 22 to a predeter- 
mined node. The node which has received this packet 
returns ack (acknowledge) or response packet subse- 
quently to ack gap. 

30 [0146] Fig. 22 is a view showing the format of a com- 
munication packet based on the asynchronous transfer 
mode in the first embodiment. The communication pack- 
et transferred based on the asynchronous transfer 
mode will be called an asynchronous packet. 

35 [0147] In Fig. 22, the asynchronous packet is made 
up of a header 2201 , header CRC 2202, data 2203, and 
data CRC 2204. 

[0148] In the header 2201, a field 2205 stores the 
node ID of a destination node; a field 2206, the node ID 
of a source node; a field 2207, a label representing a 
series of transactions; a field 2208, a code representing 
a retransmission status; a field 2209, a packet format 
and a transaction code (tcode) for identifying processing 
which must be executed; a field 2210, priority; a field 
45 2211 1 the memory address of a destination; a field 221 2, 
the length of data; and a field 2213, an extended trans- 
action code. 

[0149] A packet transferred from a transferring node 
in asynchronous transfer is transmitted to all the nodes 

so in the network, but the nodes ignore packets except for 
ones designated to the self addresses. Thus, only a des- 
tination node can read the packet. 
[0150] When asynchronous transfer reaches time at 
which the next CSP should be transferred, the next CSP 

55 is transmitted after the end of transfer without forcibly 
stopping transfer. If one communication cycle continues 
for 125 u.S or more, the next communication cycle is 
shortened. This enables the 1394 network to hold an 
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almost constant communication cycle. 
(13) Creation of Device Map 

[0151] As a means for obtaining the topology of the 
1 394 network by an application in order to create a de- 
vice map, the IEEE 1 394 standard provides the follow- 
ing means: 

1 ) The topology map register of the bus manager is 
read. 

2) The topology map is estimated from a self ID 
packet in bus reset. 

[01 52] By the means 1 ) and 2), the topology of a cable 
connection order based on the parent-child relation- 
ships between nodes can be attained, but the topology 
of a physical positional relationship cannot be attained 
(a port which is not actually mounted is listed). 
[0153] As another means, information for creating a 
device map is held in the database of a device other 
than a configuration ROM. In this case, the means for 
obtaining various pieces of information depends on pro- 
tocols for database access. On the other hand, the con- 
figuration ROM itself and the function of reading it are 
necessarily attached to an IEEE 1 394-com pliant device. 
[01 54] Thus, the first embodiment employs a function 
of storing information about the device position, func- 
tion, and the like in the configuration ROM of each node 
and reading information by an application. Accordingly, 
the application of each node can have a so-called device 
map display function regardless of specific protocols for 
database access, data transfer, and the like. 
[0155] The configuration ROM can store a physical 
position, function, and the like as node dependent infor- 
mation. Such information can be used to realize the de- 
vice map display function. 

[01 56] In this case, in order for an application to obtain 
the 1394 network topology based on the physical posi- 
tional relationship, the configuration ROM of each node 
is read-accessed in accordance with bus reset or a us- 
er's request, thereby obtaining the 1394 network topol- 
ogy. Further, various pieces of node information such as 
functions in addition to the physical position of a node 
can be described in the configuration ROM. By read- 
accessing the configuration ROM, function information 
of each node can be attained at the same time as the 
physical position of the node. When an application is to 
acquire configuration ROM information of each node, 
the application uses an API for acquiring arbitrary con- 
figuration ROM information of a designated node. 
[0157] With the use of this means, the application of 
a device on the IEEE 1394 network can create various 
device maps such as a physical topology map and the 
function map of each node in accordance with applica- 
tion purposes. The user can select a device having a 
necessary function. 



<Overview of 1 394 Bridge> 

[01 58] The configuration and connection device in the 
first embodiment will be described. 

5 [0159] The technique of an IEEE 1 394 bridge applied 
to the digital interface of the first embodiment will briefly 
be described. The standard of the IEEE 1394 bridge (to 
be referred to as a "1394 bridge" hereinafter) is being 
defined by the IEEE p1394.1. 

10 [0160] According to the 1394 standard, a maximum 
of 63 nodes can be connected to one 1394 bus, and the 
hop count is up to 16. To connect more than 63 1394 
nodes to a 1394 network, or connect devices at remote 
places by connecting more than 16 hops, a 1394 bridge 

15 is generally used. 

[0161] The IEEE 1394 standard uses 64-bit fixed ad- 
dressing according to the IEEE 1212 standard, and de- 
fines 10 bits as a bus ID. Thus, a maximum of 1,023 
buses except for ID 1 023 for designating a local bus can 

20 be connected via 1 394 bridges to constitute a 1 394 net- 
work. 

[0162] The main function of the 1394 bridge is control 
of 1394 node transaction between buses via the bridge. 
In 1394 transaction, a node which issues a transaction, 

25 i.e., issuing node is designated using a node ID as de- 
scribed in <Technical Overview of IEEE 1394 Stand- 
ards The 1 394 bridge has a table of information such 
as topology information of two connected buses and 
node ID information, and discloses partner's bus/node 

30 information to two connected buses to enable transac- 
tions between the buses. 

[0163] On the 1394 bus, bus reset occurs when the 
connection configuration changes by additionally con- 
necting a device node or when a certain node intention- 

35 ally instructs bus reset. To automatically reassign a node 
ID upon occurrence of bus reset, the bus reset se- 
quence and node ID determination sequence are done 
to create a new topology. Details of these sequences 
are described in "(6) Description of Sequence After Oc- 

40 currence of Bus Reset" and "(8) Assignment of Node 
ID" of <Technical Overview of IEEE 1394 Standard^ 
and a description thereof will be omitted. 
[0164] Because of these characteristics, topology/ 
node ID information of a connected bus dynamically 

45 changes, and the bridge updates this information. 
[0165] During the 1394 bus reset sequence, data 
transfer on the bus is suspended, and a complicated 
node ID reassignment sequence is executed. It is, there- 
fore, inefficient to propagate a bus reset signal to a bus 

50 which need not execute any bus reset sequence. For 
this reason, the 1394 bridge does not propagate the bus 
reset signal of one connected bus to the other bus. 
[0166] As another bridge function, the 1394 bridge 
has a packet routing function based on arbitration be- 

55 tween 1394 bridges and exchange of information be- 
tween bridges in a network constituted by a plurality of 
buses in which a plurality of bus bridges are connected. 
[01 67] The configuration and functions of the commu- 
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nication system constructed using the 1394 interface 
have been described. 

[Description of Configuration and Connection Device in 
First Embodiment] 

[01 68] The configuration and connection device in the 
first embodiment will be described. The configuration of 
a 1394 serial bus interface common to respective nodes 
connected to each local bus will be explained with ref- 
erence to Fig. 23. Fig. 23 is a block diagram showing 
the arrangement of the 1394 interface block of a 1394 
node in the first embodiment. 

[0169] In Fig. 23, reference numeral 2701 denotes a 
link layer control IC (LINK IC) which interfaces a device 
main body, controls data transfer of a PHY IC, and re- 
alizes the function of the link layer in <Technical Over- 
view of IEEE 1394 Standards The main function of this 
IC includes a transmission/reception FIFO function of 
temporarily storing transmission/reception data via the 
PHY IC, a function of packeting transmission data, a 
function of determining whether the PHY IC is suitable 
for an assigned channel when reception data has the 
self node address or is isochronous transfer data, a re- 
ceiver function of performing error check for the data, 
and a function of interfacing the device main body. 
[0170] Reference numeral 2702 denotes a physical 
layer control IC (PHY IC) for directly driving the 1394 
serial bus. The physical layer control IC 2702 realizes 
the function of the physical layer in <Technical Overview 
of IEEE 1394 Standards The main function of this IC 
includes bus initialization, arbitration, encoding/decod- 
ing of a transmission data code, monitoring of a cable 
ON state, supply of a load termination type power 
source (for recognizing active connection), and an inter- 
face with a link layer IC. 

[0171] Reference numeral 2703 denotes a configura- 
tion ROM which stores identification and communica- 
tion conditions unique to each device. The data format 
of this ROM complies with a format defined by the IEEE 
1212 and IEEE 1394 standards, as described in tech- 
nical Overview of IEEE 1394 Standards 
[0172] Reference numeral 2704 denotes a CPU for 
controlling 1394 interfaces such as the link layer IC and 
PHY IC; 2705, a ROM storing control programs for these 
interfaces; and 2706, a RAM used for a data buffer for 
storing transmission/reception data, a control work ar- 
ea, and the data areas of various registers mapped at 
1394 addresses. 

[0173] Each node comprises a configuration ROM of 
a general format as shown in Fig. 24. Software unit in- 
formation of each device is stored in a unit directory, 
whereas node dependent information is stored in a node 
dependent info directory. 

[0174] The basic function instance of each device 
such as a printer function or scanner function, and de- 
tailed information accessory to the basic function can 
be held by an instance directory offset from the root di- 



rectory. 

[01 75] The format of the instance directory will be de- 
scribed. The instance directory stores information of a 
device such as a printer or scanner which does not de- 
5 pend on protocols. For a single-function device, basic 
function information is one. For a device which supports 
a plurality of functions, a plurality of functions are listed. 
For each of the listed functions, the instance directory 
stores pointer information to a unit directory for storing 
to corresponding protocol software information, and a 
pointer to a feature directory for holding detailed infor- 
mation unique to each function. 
[0176] As described in <Technical Overview of IEEE 
1394 Standards the last 28 bits out of the address set- 
15 ting of the 1394 serial bus are ensured as the unique 
data area of each device which can be accessed by an- 
other device connected to the serial bus. Fig. 25 is a 
view showing the address space of the 28-bit area serv- 
ing as the unique data area of each device. 
[0177] CSR core registers shown in Fig. 11 are ar- 
ranged in an area from address 0000 to address 0200 
in Fig. 25. These registers exist as basic functions for 
node management defined by the CSR architecture. 
[01 78] An area from address 0200 to address 0400 is 
defined by the CSR architecture as an area for storing 
serial bus dependent registers. Fig. 26 shows an exam- 
ple of the area for storing serial bus dependent registers 
according to the first embodiment. As described in 
<Technical Overview of IEEE 1 394 Standards registers 
at address 0200 to address 0230 are defined and used 
for synchronization of data transfer, supply of power, 
management of the bus resource, and the like. This is 
the same as the arrangement shown in Fig. 12. 
[0179] A register REMOTE_BUS_RESET arranged 
at address 0240 in Fig. 26 is a feature of the first em- 
bodiment. The format of this register is shown in Fig. 27. 
[0180] A node in which data prepared by substituting 
an effective bus ID in a BUSJD field in accordance with 
the format of Fig. 27 is written by a 1 394 write transac- 
tion to this register can know occurrence of bus reset in 
a remote bus represented by the BUSJD field other 
than a local bus connected to this node. The above- 
mentioned configuration ROM is arranged in an area 
from address 0400 to address 0800. 
[0181] An area from address 0800 to address 1000 
shown in Fig. 25 stores the current 1394 bus topology 
information and information about the transfer speed 
between nodes. An area after address 1000 is called a 
unit space where registers concerning operations 
unique to each device are arranged. This area stores 
registers and a data transfer memory mapped buffer ar- 
ea defined by upper protocols supported by each de- 
vice, or device dependent registers. 
[0182] The operation of the first embodiment in a 1394 
network where devices A1 and A2 each having a 1 394 
interface constituted in the above manner are connect- 
ed to the bus A, devices B1 and B2 are connected to 
the bus B, and the buses A and B are connected by a 
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1394 bridge device will be explained with reference to 
Figs. 28 and 29. Fig. 28 is a view showing communica- 
tion control procedures complying with a DPP protocol 
in the first embodiment, and Fig. 29 is a view showing 
communication control procedures complying with an 5 
AV/C protocol in the first embodiment. 
[0183] Before the buses A and B attain their current 
connection configurations, bus reset independently oc- 
curs on each bus every time a device node is addition- 
ally connected. A bus reset sequence and bus ID deter- 10 
mination sequence are executed to automatically as- 
sign a node ID upon occurrence of bus reset, and a new 
topology is created. 

[0184] Then, 1394 data transfer starts on each bus. 
Details of these sequences are described in "(6) De- *5 
scription of Sequence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technical Overview 
of IEEE 1394 Standards and a description thereof will 
be omitted. Although the operation changes depending 
on the connection order of connection nodes and the 20 
connection order of buses to the 1 394 bridge, the bus 
reset- 1394 initialization sequence is repeated every 
time a node is connected. Finally, a topology in which 
devices A1 and A2 are connected to the bus A via the 
1394 bridge 101 ( and devices B1 and B2 are connected 25 
to the bus B is formed. 

[0185] While the topology of the 1394 network is de- 
termined in this state, and 1 394 data transfer is normally 
performed, the node A1 as a digital still camera having 
a direct print protocol (to be referred to as a "DPP") as so 
an upper protocol searches for a printer device which 
supports the DPP on the 1394 network, like the self 
node, in order to transfer image data to a printer con- 
nected to the 1394 network and print the image data in 
accordance with user operation or the trigger of an ap- 35 
plication. 

[0186] This is realized by read-accessing the config- 
uration ROM of a partner node for a node connected to 
the network. This is shown in Fig. 19. More specifically, 
the node uses an IEEE 1394 read transaction for the 40 
partner node to receive the ROM contents of the partner 
node as a read response. 

[0187] As described above, 1394-related information 
is described in the configuration ROM of each node. Fur- 
ther, the basic function of each node such as a printer 45 
or camera is described in the instance directory, and an 
upper protocol such as an AV/C protocol or DPP and 
software information are described in the unit directory. 
[0188] While the node A1 read-accesses the ROM of 
each node on the local bus A, and then read-accesses so 
the ROM of each node on the bus B via the 1 394 bridge, 
the node A1 detects that the node B1 is a printer as a 
DPP device. 

[0189] Although details of a 1394 transaction via the 
1 394 bridge will be omitted, its standard is being defined 55 
by IEEE p1 394.1. 

[01 90] After the camera as the node A1 finds the node 
B1 which is a printer and has the same protocol as the 



DPP protocol supported by the node A1 , the node A1 
establishes connection with the node B1 in accordance 
with procedures and a format defined by the DPP pro- 
tocol shown in Fig. 28. 

[0191] More specifically, the node A1 transmits a con- 
nection request command to the node B1 using a write 
transaction, as shown in ©of Fig. 28. In response to 
this, the node B1 transmits a connection request re- 
sponse using a write transaction, as shown in@of Fig. 
28. Then, transfer of application data starts. 
[0192] Similarly, the node B2 as a digital video cam 
coder having an AV/C protocol as an upper protocol 
starts transmission/reception of an AV/C command with 
the node A2 via the 1 394 bridge using an AV/C protocol 
shown in Fig. 29. The node B2 issues an AV/C com- 
mand, and enters a response wait state, as shown in® 
of Fig. 29. 

[0193] Assume that a device node A3 (1 08) shown in 
Fig. 1 is newly connected to the bus A by user operation 
in this network state. Since the new node is additionally 
connected, bus reset occurs in accordance with IEEE 
1394 characteristics. 

[0194] The 1394 interface layer of each node on the 
bus A which has received a bus reset signal notifies the 
upper protocol layer of this information. At the same 
time, the node starts a series of bus reset resume proc- 
esses such as a bus reset sequence and node ID de- 
termination sequence in order to automatically assign a 
node ID upon occurrence of bus reset. 
[0195] After bus reset on the bus A 1 02 is notified to 
the DPP layer, the node A1 (104), which establishes 
connection with the node B1 (106) on the bus B 103 in 
accordance with a DPP protocol on the bus A 102 and 
performs data transfer, starts bus reset resume process- 
ing complying with the DPP protocol. 
[0196] In bus reset resume processing by DPP, when 
data transfer normally restarts after bus reset resume 
processing ends in the 1 394 layer to determine a new 
node ID and topology, a node which has first transmitted 
a connection request to a partner node within a prede- 
termined time before data transmission restarts trans- 
mits a reconnection request command. 
[0197] After bus reset resume is completed in the 
1394 interface layer, a node which has received a re- 
quest in establishment of connection enters a reception 
wait state for a reconnection request command from the 
node which has established connection. If the node 
does not receive any command, it abandons the con- 
nection. 

[0198] After bus reset on the bus A 102 is notified to 
the AV/C layer, the node B1 (106) which is transferring 
data to the node B2 (107) on the bus B 103 in accord- 
ance with an AV/C protocol on the bus A 102 starts bus 
reset procedure processing. 

[0199] In the AV/C protocol, a node which has re- 
ceived an AV/C command transmitted by one node gen- 
erally transmits a paired response containing informa- 
tion such as command execution results and the like to 
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the command issuing node. Upon occurrence of bus re- 
set, an AV/C command sent before reset for which no 
response is received is regarded not to be executed and 
to be abandoned. Thus, an AV/C command must be re- 
sent after bus reset processing ends in the 1394 inter- 5 
face layer, and data transfer normally resumes. 
[0200] On the bus B 103 whose connection configu- 
ration is not changed, no bus reset occurs in accordance 
with the IEEE standard. Even if bus reset occurs on the 
bus A 102 connected via the 1394 bridge 101, the bus to 
B 103 detects this, but the 1394 bridge 101 does not 
propagate any bus reset signal to another bus, i.e., the 
bus B 103 in this case because of defined characteris- 
tics. 

[0201] Hence, only nodes such as the nodes A1 , A2, 15 
and A3 connected to the bus A 102 start bus reset 
resume processing. The node B1 (106) as the data 
transmission destination of the node A1 (104) and the 
node B2 (107) as the data transmission destination of 
the node A2 (105) do not start this processing. 20 
[0202] In the 1 394 network system of the first embod- 
iment, the 1 394 bridge comprises a means for notifying, 
of bus reset occurrence information on one bus, a node 
connected to the other bus, and each node comprises 
a means for receiving a bus reset occurrence notifica- 25 
tion from a remote bus. 

[0203] More specifically, the 1394 bridge 101 which 
has received a bus reset signal upon occurrence of bus 
reset on the bus A executes bus reset processing on the 
node controller side. At the same time, the 1394 bridge 30 
101 notifies the node controller side of the bus B of oc- 
currence of bus reset together with bus ID information 
of the bus A, i.e., a value 3FDh. 
[0204] The node controller of the bus B which has re- 
ceived this information uses a 1 394 write transaction to 35 
write a packet containing data representing the bus ID: 
3 FDh of the remote bus suffering bus reset in the reg- 
ister n REMOTE_BUS_RESET" arranged at address 
0240 of each node connected to the bus B in accord- 
ance with the format of this register. <o 
[0205] Although no bus reset occurs on the bus B, the 
bus B is notified of occurrence of bus reset on the remote 
bus A by writing the ID of the bus A in the 
REMOTE_BUS_RESET register of each node by the 
1 394 bridge 1 01 , as shown in ®of Fig. 28 or@of Fig. 29. 45 
[0206] The 1 394 interface layer of each node on the 
bus B which has detected write in the 
REMOTE_BUS_ RESET register notifies the upper pro- 
tocol layer of occurrence of bus reset on the remote bus 
and bus ID information of the remote bus. so 
[0207] The node B1, which has established connec- 
tion with the node A1 on the bus A in accordance with 
a DPP protocol on the bus B and has performed data 
transfer, checks the ID of the remote bus suffering bus 
reset, and confirms that the remote bus is the bus A con- 55 
nected to a node as the connection destination of the 
node B1. Then, the node B1 recognizes that the con- 
nection destination node, i.e., node A1 has started bus 



reset resume processing complying with a DPP proto- 
col. 

[0208] The node B1 also starts processing corre- 
sponding to DPP bus reset processing, and enters a re- 
ception wait state for a reconnection request command 
from the node with which the node B1 establishes con- 
nection. This ensures the consistency of DPP protocol 
processing between the node A1 which starts bus reset 
processing after bus reset actually occurs, and the node 
B1 connected to the bus B on which no bus reset occurs. 
[0209] After that, the node A1 transmits a reconnec- 
tion request command shown in@of Fig. 28 to the node 
B1, and the node B1 transmits a reconnection request 
response shown in ©of Fig. 28 to the node A1 , thereby 
restarting data communication. 
[0210] Similarly, the node B2, which has exchanged 
an AV/C command with the node A2 on the bus A in 
accordance with an AV/C protocol on the bus B, checks 
the ID of the remote bus suffering bus reset, and con- 
firms that the remote bus is the bus A connected to the 
node A2 as a connection destination node. Then, the 
node B2 recognizes that the connection destination 
node, i.e., node A2 has started bus reset processing ac- 
cording to an AV/C protocol. 

[0211] The node B2 also executes processing corre- 
sponding to AV/C bus reset processing shown in Fig. 
29, and processing in which an AV/C command sent be- 
fore remote bus reset for which no response is received 
is regarded not to be executed and to be abandoned. 
This ensures the consistency of AV/C protocol process- 
ing between the node A2 which starts bus reset process- 
ing after bus reset actually occurs, and the node B2 con- 
nected to the bus B on which no bus reset occurs. 
[0212] The node B2 resends an AV/C command 
shown in@of Fig. 29 to the node A2. In response to this, 
the node A2 transmits an AV/C response shown in@of 
Fig. 29 to the node B2, thereby continuing communica- 
tion. 

[0213] As described above, the first embodiment pro- 
vides a 1394 bus system characterized in that a node 
connected to an IEEE 1394 bus comprises a means ca- 
pable of receiving the ID of a bus suffering bus reset and 
a reset occurrence notification when bus reset occurs 
on a remote bus other than a bus connected to the self 
node, and if a plurality of buses are connected via bridg- 
es, a bridge connected to the bus suffering bus reset 
transmits to the reception means of other connected 
buses a remote bus reset occurrence notification con- 
taining the ID of the bus suffering bus reset. When bus 
reset occurs on one local bus in performing data transfer 
from a data transmission node on one local bus to a data 
reception node connected to the other local bus via a 
1394 bridge, the 1394 bridge can notify the node con- 
nected to the remote bus of bus reset. The reception 
node connected to the other bus can detect bus reset 
to maintain the consistency of bus reset processing in 
the upper protocol layer. This enables normal data com- 
munication between buses. 
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[0214] The first embodiment can further provide a 
node connected to an IEEE 1394-compliant communi- 
cation control bus with a means capable of receiving the 
ID of a bus suffering bus reset and a reset occurrence 
notification when bus reset occurs on a remote bus other 
than a local bus connected to the self node. 
[0215] As the remote bus reset occurrence notifica- 
tion reception means, the first embodiment can provide 
a means for storing a register at a predetermined ad- 
dress on the node, and detecting write of bus ID infor- 
mation at the address to receive a remote bus reset oc- 
currence notification. 

[0216] Further, the first embodiment can provide an 
information signal processing apparatus characterized 
in that the predetermined register is arranged in the core 
CSR architecture register space or serial bus register 
space in the address space of each 1394 node. 
[0217] The first embodiment can provide a 1394 bus 
system characterized in that occurrence of remote bus 
reset is notified when a plurality of buses are connected 
via bridges in an IEEE 1394 bus system, and bus reset 
occurs in a remote bus other than connected buses. 
Moreover, this embodiment can provide a 1394 bus sys- 
tem characterized in that a bridge connected to a bus 
suffering bus reset transmits to the node of another con- 
nected bus a remote bus reset occurrence notification 
containing the ID of the bus suffering bus reset. 

[Second Embodiment] 

[0218] The second embodiment according to the 
present invention will be described below. In the second 
embodiment, the configuration and function of a com- 
munication system using a 1394 interface are the same 
as those in the first embodiment, and a detailed descrip- 
tion thereof will be omitted. 

[0219] In the second embodiment, the same refer- 
ence numerals as in the first embodiment denote the 
same parts in the configuration and connection device 
of the second embodiment, and a detailed description 
thereof will be omitted. 

[0220] In the second embodiment, a 1394 serial bus 
interface can be constituted similarly to the first embod- 
iment shown in Fig. 23, and the configuration ROM of 
each node can adopt the same formats as those shown 
in Figs. 24 and 25. The second embodiment is different 
from the first embodiment in that the format of an area 
from address 0200 to address 0400 shown in Fig. 25 for 
storing serial bus dependent registers has the format 
shown in Fig. 30. 

[0221] In the second embodiment, 
NOTIFY_BUS_RESET arranged at address 0244 is as- 
signed in addition to serial bus dependent registers 
shown in Fig. 26, and is a characteristic register of the 
second embodiment. The format of the 
NOTIFY_BUS_RESET register will be explained with 
reference to Fig. 31 . Fig. 31 is a view showing the format 
of the NOTIFY_BUS_RESET register in the second em- 



bodiment. 

[0222] The NOTIFY_BUS_RESET register is a regis- 
ter mounted on the bridge portal of a 1394 bridge 101 
(to be described below) to which the second embodi- 

5 ment is applied. According to a 1394 write transaction, 
a data with a format of Fig. 31 is written into the register. 
If an effective bus ID, an effective node ID and an effec- 
tive command (1 : store, 0: delete) are respectively sub- 
stituted in a BUSJD field, a NODEJD field and a com- 

to mand field of the data written in the register, the bridge 
1 0 1 receives the data as an effective data, and executes 
process according to the value of the command field. If 
the value of the command field is "1" (store), the bridge 
101 stores the values of BUSJD field and NODEJD 

15 field of the received data into the storage table corre- 
sponds to the portal. If the value of the command field 
is "0" (delete), the bridge 101 deletes the values of 
BUSJD field and NODEJD field of the received data 
from the storage table corresponds to the portal. When 

20 a bus reset occurs in the 1394 bus to which the portal 
is connected, the bridge 101 notifies the occurrence of 
the bus reset to the node by writing, according to the 
1394 write transaction, to a REMOTE_BUS_RESET 
register of the node designated by the bus ID and node 

25 id stored in the storage table. 

[0223] Fig. 32 is a block diagram showing the ar- 
rangement of the IEEE 1394 bridge 101 in the second 
embodiment. In Fig. 32, a portal A 3301 is connected to 
a bus A 102, whereas a portal B 3302 is connected to 

30 a bus B 103. Each portal functions as one node con- 
nected to the bus. 

[0224] A bridge controller 3303 has a function of 
bridging the portals A 3301 and B 3302. A bus reset 
manager 3304 stores or deletes a bus ID and node ID 

35 written in the NOTIFY_BUS_RESET register of the por- 
tal A 3301 in or from a storage table A 3305. 
[0225] Similarly, the bridge controller 3303 stores or 
deletes a bus ID and node ID written in the 
NOTIFY_BUS_RESET register of the portal B 3302 in 

40 or from a storage table B 3306. The bridge controller 
3303 notifies a node of occurrence of bus reset by writ- 
ing data in accordance with the same format of Fig. 27 
as in the first embodiment in the REMOTE_BUS RESET 
register of the node stored in the storage table A 3305 

45 when bus reset occurs on the bus A 102, or in the stor- 
age table B 3306 when bus reset occurs on the bus B 
103. 

[0226] The configuration ROM is arranged in an area 
from address 0400 to address 0800. 

so [0227] Similar to the first embodiment, an area from 
address 0800 to address 1000 shown in Fig. 25 stores 
the current 1394 bus topology information and informa- 
tion about the transfer speed between nodes. An area 
after address 1000 is called a unit space where registers 

55 concerning operations unique to each device are ar- 
ranged. This area stores registers and a data transfer 
memory mapped buffer area defined by upper protocols 
supported by each device, or device dependent regis- 
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ters. 

[0228] A detailed operation in a 1 394 network shown 
in Fig. 1 where the nodes A1 (104) and A2 (105) each 
having a 1 394 interface constituted in the above manner 
are connected to the bus A 102, the nodes B1 (106) and 
B2 (107) are connected to the bus B 103, and the bus 
A 102 and bus B 103 are connected by the 1394 bridge 
101 will be explained with reference to Figs. 33 and 34. 
Fig. 33 is a view showing communication control proce- 
dures complying with a DPP protocol in the second em- 
bodiment, and Fig. 34 is a view showing communication 
control procedures complying with an AV/C protocol in 
the second embodiment. 

[0229] Before buses A and B attain their current con- 
nection configurations, bus reset independently occurs 
on each bus every time a device node is additionally 
connected. Upon occurrence of bus reset, a node ID is 
automatically assigned. For this purpose, a bus reset 
sequence and bus ID determination sequence are exe- 
cuted to create a new topology. 
[0230] Then, 1394 data transfer starts on each bus. 
Details of these sequences are described in "(6) De- 
scription of Sequence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technical Overview 
of IEEE 1394 Standards and a description thereof will 
be omitted. 

[0231] Although the operation changes depending on 
the connection order of connection nodes and the con- 
nection order of buses to the 1394 bridge 101, the bus 
reset-1394 initialization sequence is repeated every 
time a node is connected. Finally, a topology in which 
devices A1 and A2 are connected to the bus A via the 
1 394 bridge 1 01 , and devices B1 and B2 are connected 
to the bus B is formed. 

[0232] While the topology of the 1394 network is de- 
termined in this state, and 1 394 data transfer is normally 
performed, the node A1 as a digital still camera having 
a direct print protocol (to be referred to as a "DPP") as 
an upper protocol searches for a printer device which 
supports the DPP on the 1394 network, like the self 
node, in order to transfer image data to a printer con- 
nected to the 1394 network and print the image data in 
accordance with user operation or the trigger of an ap- 
plication. 

[0233] This is realized by read-accessing the config- 
uration ROM of a partner node for a node connected to 
the network. This is shown in Fig. 19. More specifically, 
the node uses an IEEE 1394 read transaction for the 
partner node to receive the ROM contents of the partner 
node as a read response. 

[0234] As described above, 1394-related information 
is described in the configuration ROM of each node. Fur- 
ther, the basic function of each node such as a printer 
or camera is described in the instance directory, and an 
upper protocol such as an AV/C protocol or DPP and 
software information are described in the unit directory. 
[0235] While the node A1 read-accesses the ROM of 
each node on the local bus A, and then read-accesses 



the ROM of each node on the bus B via the 1394 bridge, 
the node A1 detects that the node B1 is a printer as a 
DPP device. 

[0236] Although details of a 1394 transaction via the 
5 1394 bridge will be omitted, its standard is being defined 
by IEEEp1394.1. 

[0237] After the camera as the node A1 (104) finds 
the node B1 (106) which is a printer and has the same 
protocol as the DPP protocol supported by the node A1 , 

10 the node A1 establishes connection with the node B1 in 
accordance with procedures and a format defined by the 
DPP protocol shown in Fig. 33, and starts data transfer. 
[0238] At this time, as shown in ®of Fig. 33, the node 
A1 (1 04) writes {(bus ID of bus B), (node ID of node B1 ), 

15 (storage command)} in the NOTIFY_BUS_RESET reg- 
ister of the portal A 3301 of the 1394 bridge 101 in ac- 
cordance with the format shown in Fig. 31 . The node A1 
(104) transmits a connection request command to the 
node B1 using a write transaction shown in@of Fig. 33. 

20 [0239] In response to this, as shown in (§)of Fig. 33, 
the node B1 (106) writes {(bus ID of bus A), (node ID of 
node A1), (storage command)} in the 
NOTIFY„BUS_RESET register of the portal B 3302 of 
the 1394 bridge 101 in accordance with the format of 

25 Fig. 31. 

[0240] The node B1 (106) transmits a connection re- 
quest response to the node A1 using a write transaction 
shown in@bf Fig. 33. In this way, the node A1 (104) es- 
tablishes connection with the node B1 (106), and the 

30 bus reset manager of the 1 394 bridge stores these bus 
IDs and node IDs in corresponding storage tables. 
[0241] Similarly, the node B2 (107) as a digital video 
cam coder having an AV/C protocol as an upper protocol 
starts transmission/reception of an AV/C command with 

35 the node A2 (105) via the 1394 bridge using an AV/C 
protocol. For this purpose, the node B2 (107) performs 
the same write operation as ®of Fig. 33 in the bridge 
1 01 so as to enable notifying a partner node of bus reset, 
as shown in ©of Fig. 34. 

40 [0242] The node B2 (107) issues an AV/C command 
shown in ©of Fig. 34, and enters a response wait state. 
Also, the node A2 (105) which has received the AV/C 
command shown in ©of Pig. 34 performs the same write 
operation as@of Fig. 33 in the bridge 101 so as to en- 

45 able notifying a partner node of bus reset, as shown in 
(Dof Fig. 34. 

[0243] Assume that a device node A3 (1 08) shown in 
Fig. 1 is newly connected to the bus A by user operation 
in this network state. Then, bus reset occurs in accord- 
so ance with IEEE 1394 characteristics. 

[0244] In this case, no bus reset occurs on the bus B 
103 whose connection configuration does not change. 
The node B1 (106) serving as the data transmission 
destination of the node A1 (104), and the node B2 (107) 
55 serving as the data transmission destination of the node 
A2 (105) do not start bus reset resume processing. 
[0245] However, this causes the above problem, so 
that the second embodiment executes the following op- 



17 



33 



EP 1 134 937 A1 



34 



eration instead of the defined operation. 
[0246] In the 1 394 network system of the second em- 
bodiment, the bus reset manager 3304 of the 1394 
bridge 101 comprises a means for notifying, of bus reset 
occurrence information on a bus connected to a bridge 
portal, a node stored in a storage table corresponding 
to this portal. Each node comprises a means for receiv- 
ing a sub reset occurrence notification on a remote bus. 
This arrangement solves the above problem. 
[0247] More specifically, the 1394 bridge 101 which 
has received a bus reset signal upon occurrence of bus 
reset on the bus A 102 performs bus reset processing 
by the node controller of the portal A 3301 connected to 
the bus A 1 02. The bus reset manager 3304 uses a 1 394 
write transaction to sequentially write packets contain- 
ing data of the bus ID of a remote bus, i.e., the bus ID: 
3FDh of the bus A suffering bus reset in accordance with 
the register format in the REM OTE_BUS_ RESET reg- 
isters arranged at address 0240 of the serial bus regis- 
ters of respective nodes shown in Fig. 30 that are stored 
in the storage tables 3305 and 3306. 
[0248] In the second embodiment, the bus IDs and 
node IDs of the node B1 (106) and node B2 (107) are 
stored in the storage tables, so that data are written in 
these nodes, as shown in ©of Fig. 33 or@of Fig. 34. 
[0249] As a result, the bus B 1 03 does not suffer bus 
reset, but can be notified of occurrence of bus reset on 
the remote bus A by writing the ID of the bus A 102 in 
the REMOTE_BUS_RESET register of each node that 
should be notified by the bridge 101. 
[0250] The 1394 interface layer of each node which 
has detected write in the REMOTE_BUS RESET regis- 
ter notifies the upper protocol layer of occurrence of bus 
reset on a remote bus and the bus ID information of the 
remote bus. 

[0251] The node B1 (106), which establishes connec- 
tion with the node A1 (104) on the bus A in accordance 
with a DPP protocol on the bus B and performs data 
transfer, checks the ID of the remote bus suffering bus 
reset, and confirms that the remote bus is the bus A 1 02 
connected to a node as the connection destination of 
the node B 1 . Then, the node B 1 recognizes that the con- 
nection destination node, i.e., node A1 (104) has started 
bus reset resume processing complying with a DPP pro- 
tocol. 

[0252] The node B1 (106) also starts processing cor- 
responding to DPP bus reset processing, and enters a 
reception wait state for a reconnect ion request com- 
mand from the node with which the node B1 (106) es- 
tablishes connection. This ensures the consistency of 
DPP protocol processing between the node A1 (104) 
which starts bus reset processing after bus reset actu- 
ally occurs, and the node B1 (1 06) connected to the bus 
B 103 on which no bus reset occurs. 
[0253] After that, the node A1 (1 04) transmits a recon- 
nection request command shown in ©of Fig. 33 to the 
node B1 (106), and the node B1 (106) transmits a re- 
connection request response shown in ©of Fig. 33 to 



the node A1 (104), thereby restarting data communica- 
tion. 

[0254] Similarly, the node B2 (1 07), which exchanges 
an AV/C command with the node A2 (105) on the bus A 
5 102 in accordance with an AV/C protocol on the bus B 
1 03, checks the ID of the remote bus suffering bus reset, 
and confirms that the remote bus is the bus A 102 con- 
nected to the node A2 (105) as the connection destina- 
tion of the node B2. Then, the node B2 (107) recognizes 
that the connection destination node, i.e., node A2 (1 05) 
has started bus reset processing according to an AV/C 
protocol. The node B2 (107) also executes processing 
corresponding to AV/C bus reset processing, and 
processing in which an AV/C command sent before re- 
mote bus reset for which no response is received is re- 
garded not to be executed and to be abandoned. This 
ensures the consistency of AV/C protocol processing 
between the node A2 (105) which starts bus reset 
processing after bus reset actually occurs, and the node 
B2 (107) connected to the bus B 103 on which no bus 
reset occurs. 

[0255] The node B2 (1 07) resends an AV/C command 
shown in ©of Fig. 34 to the node A2 (1 05), In response 
to this, the node A2 (105) transmits an AV/C response 
shown in ©of Fig. 34 to the node B2 (1 07), thereby con- 
tinuing communication. 

[0256] Even when bus reset occurs on the bus B 1 03, 
the bus reset manager 3304 of the 1394 bridge 101 sim- 
ilarly notifies a target node on the bus A 102 of occur- 
rence of bus reset, thereby maintaining the consistency 
of upper protocol processing. 

[0257] As described above, the second embodiment 
provides an IEEE 1 394 bridge having at least two portals 
respectively connected to different IEEE 1394 buses, 
characterized by comprising a bus reset management 
means made up of a means for monitoring bus reset of 
the IEEE 1394 buses inserted/removed to/from the re- 
spective portals, a means for designating either one of 
the IEEE 1394 buses connected to the respective por- 
tals, a means for designating a node on a network con- 
stituted by a plurality of IEEE 1394 buses connected via 
bridges, and a means for notifying the designated node 
of bus reset of the designated bus. This IEEE 1394 
bridge can notify a node connected to a remote bus of 
occurrence of bus reset. 

[Third Embodiment] 

[0258] In the third embodiment, the basic configura- 
tion is the same as in the first and second embodiments 
shown in Figs. 1 to 34, and a detailed description thereof 
will be omitted. Only the difference from the first and sec- 
ond embodiments will be described. The third embodi- 
ment is different from the second embodiment in com- 
munication control procedures complying with a DPP 
protocol. Communication control procedures complying 
with a DPP protocol in the third embodiment according 
to the present invention will be described with reference 



15 



20 



25 



30 



35 



40 



45 



50 



18 



35 



EP 1 134 937 A1 



36 



to Fig. 35. 

[0259] Similar to the second embodiment, while the 
topology of a 1 394 network is determined, and 1 394 da- 
ta transfer is normally performed, a node A1 as a digital 
still camera having a DPP as an upper protocol search- 5 
es for a printer device which supports the DPP on the 
1394 network, like the self node, in order to transfer im- 
age data to a printer connected to the 1 394 network and 
print the image data in accordance with user operation 
or the trigger of an application. 
[0260] While the node A1 read-accesses the ROM of 
each node on a local bus A 1 02, and then read-accesses 
the ROM of each node on a bus B 1 03 via a 1 394 bridge, 
the node A1 detects that a node B1 is a printer as a DPP 
device. Assume that the node B1 comprises a 
REMOTE_BUS_RESET register, but the node A1 does 
not comprise it. The node B1 can know this from ROM 
information of the node A1. 

[0261] In the third embodiment, when (3FFH) and 
(3FH) are respectively written in the bus ID field and 
node ID field of the format shown in Fig. 31 in the 
NOTIFY_BUS„RESET register of a bridge portal, a bus 
reset manager 3304 of a 1 394 bridge 1 01 stores the bus 
ID and node ID of the writing node in a storage table 
corresponding to the written portal. 
[0262] After the camera as the node A1 finds the node 
B1 which is a printer and has the same protocol as the 
DPP protocol supported by the node A1, the node A1 
establishes connection with the node B1 in accordance 
with procedures and a format defined by the DPP pro- 
tocol. To start transferring application data, the node A1 
transmits a connection request shown in ®of Fig. 35 to 
the node B1 using a write transaction. 
[0263] At this time, as shown in@of Fig. 35, the node 
B1 writes {(3FFH), (3FFH), (storage command)} in the 
NOTIFY BUS RESET register of the portal A 3301 of 
the 1 394 bridge in accordance with the format of Fig. 31 . 
[0264] The bus reset manager of the 1394 bridge 
stores the bus ID and node ID of the node B1 in a storage 
table corresponding to the portal A. Then, the node B1 
transmits a connection request response shown in@of 
Fig. 35 to the node A1 using a write transaction, and 
establishes connection. 

[0265] Similar to the second embodiment, assume 
that a device node A3 (108 shown in Fig. 1) is newly 
connected to the bus A 1 02 by user operation in the net- 
work state shown in Fig. 1 . Part of this control is different 
from the second embodiment. 
[0266] Since the new node is additionally connected, 
bus reset occurs in accordance with IEEE 1394 charac- 
teristics. The 1394 interface layer of each node on the 
bus A 102 which has received a bus reset signal notifies 
the upper protocol layer of this information. At the same 
time, the node starts a series of bus reset resume proc- 
esses such as a bus reset sequence and node ID de- 
termination sequence in order to automatically assign a 
node ID upon occurrence of bus reset. 
[0267] After bus reset on the bus A 102 is notified to 



the DPP layer, the node A1 ( 1 04), which has established 
connection with the node B1 (106) on the bus B 103 in 
accordance with a DPP protocol on the bus A 102 and 
has performed data transfer, starts bus reset resume 
processing complying with the DPP protocol, similar to 
the first embodiment. 

[0268] On the other hand, when no bus reset occurs 
in the bus B 103 whose connection configuration does 
not change, and bus reset occurs on the bus A 102, as 
described in the first embodiment, a bus reset signal is 
not propagated to the bus B 1 03. At this time, only nodes 
such as the nodes A1 , A2, and A3 connected to the bus 
A start bus reset resume processing. The node B1 as 
the data transmission destination of the node A1 and 
the node B2 as the data transmission destination of the 
node A2 do not start this processing. 
[0269] In the third embodiment, as well as the first em- 
bodiment, the 1 394 bridge 101 which has received a bus 
reset signal upon occurrence of bus reset on the bus A 
102 executes bus reset processing on the node control- 
ler side of the portal A 3301 connected to the bus A 1 02. 
The bus reset manager 3304 uses a 1394 write trans- 
action to sequentially write packets containing data of 
the bus ID of a remote bus, i.e., the bus ID: 3FDh of the 
bus A 1 02 suffering bus reset in accordance with the 
register format in REMOTE_BUS_RESET registers ar- 
ranged at address 0240 of respective nodes stored in 
storage tables 3305 and 3306. At the same time, the 
bus reset manager 3304 also writes data in the node 
B1 , as shown in @of Fig. 35. 

[0270] Although no bus reset occurs on the bus B, the 
bus B is notified of occurrence of bus reset on the remote 
bus A by writing the ID of the bus A 102 in the 
REMOTE_BUS„RESET register of each target node by 
the 1394 bridge 101. 

[0271] The 1394 interface layer of each node which 
has detected write in the REMOTE_BUS_RESET reg- 
ister notifies the upper protocol layer of occurrence of 
bus reset on the remote bus and bus ID information of 
the remote bus. 

[0272] ThenodeBI (106), which has established con- 
nection with the node A1 (104) on the bus A 102 in ac- 
cordance with a DPP protocol on the bus B 1 03 and has 
performed data transfer, checks the ID of the remote bus 
suffering bus reset, and confirms that the remote bus is 
the bus A connected to a node as the connection des- 
tination of the node B1 (106). Then, the node B1 (106) 
recognizes that the connection destination node, i.e., 
node A1 (104) has started bus reset resume processing 
complying with a DPP protocol. 
[0273] The node B1 (106) also starts processing cor- 
responding to DPP bus reset processing, and enters a 
reception wait state for a reconnection request com- 
mand from the node with which the node B1 (106) es- 
tablishes connection. This ensures the consistency of 
DPP protocol processing between the node A1 which 
starts bus reset processing after bus reset actually oc- 
curs, and the node B1 connected to the bus B on which 
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no bus reset occurs. 

[0274] Thereafter, the node A1 transmits a reconnec- 
tion request command shown in(Dof Fig. 35 to the node 
B1, and the node B1 transmits a reconnection request 
response shown in ©of Fig. 35 to the node A1 , thereby 
restarting data communication. 
[0275] If bus reset occurs on the bus B, the node A1 
on the bus A does not know occurrence of bus reset on 
the bus B. During bus reset on the bus B, the request of 
the node A1 is held by the bridge, and sent to the node 
B1 by the bridge after the end of bus reset on the bus 
B, as shown in ®of Fig. 35. The node B1 transmits a 
reconnection request response to the node A1, as 
shown in(Dof Fig. 35, and can restart data communica- 
tion. 

[0276] Since the node B1 can maintain consistency 
after the end of bus reset, the node B1 can restart com- 
munication in response to a request from the node A1 , 
as shown in Fig. 35. 

[0277] As described above, the third embodiment pro- 
vides an information communication system including a 
first IEEE 1394 bus connected to an IEEE 1394 bridge, 
a first node connected to the first IEEE 1394 bus, a sec- 
ond IEEE 1394 bus different from the first IEEE 1394 
bus, and a second node connected to the second IEEE 
1394 bus, the first and second nodes communicating 
with each other, characterized in that the first node in- 
structs the IEEE 1 394 bridge connected to the first IEEE 
1394 bus to monitor bus reset on the first IEEE 1394 
bus and notify the second node of bus reset on the first 
IEEE 1394 bus. This information communication system 
can notify a communication partner node connected to 
a remote bus of occurrence of bus reset on a bus con- 
nected to the self node. 

[0278] If bus reset occurs on one local bus in perform- 
ing data transfer from a data transmission node on one 
local bus to a data reception node connected to the other 
local bus via a 1394 bridge using the same upper pro- 
tocol, the 1394 bridge can notify the node connected to 
the remote bus of bus reset. The reception node con- 
nected to the other bus can detect the bus reset, and 
maintain the consistency of bus reset processing in the 
upper protocol layer. This enables normal data commu- 
nication between buses. 

[Fourth Embodiment] 

[0279] Fig. 36 is a block diagram showing the config- 
uration of the fourth embodiment according to the 
present invention. 

[0280] In the fourth embodiment, as shown in Fig. 36, 
a 1 394 bridge A 3401 is connected to a bus A via a portal 
A, and to a bus C via a portal C1 . A 1 394 bridge B 3402 
is connected to a bus B via a portal B, and the bus C via 
a portal C2. 

[0281] The bus A is connected to a node A1 (3403) 
and node A2 (3404), the bus B is connected to a node 
B1 (3405) and node B2 (3406), and the bus C is con- 



nected to a node C1 (3407) and node C2 (3408). 
[0282] The bus A has a bus ID (3FDh), the bus B has 
a bus ID (3FEh), and the bus C has a bus ID (3FCh). 
[0283] The system of the fourth embodiment has the 

5 same building components as those in the third embod- 
iment, and the 1394 bridge has the same arrangement 
as that shown in Fig. 32. Only the difference from the 
third embodiment will be described below. 
[0284] In the fourth embodiment, as well as the see- 
to ond embodiment, after a camera as the node A1 finds 
the node B 1 which is a printer and has the same protocol 
as the DPP protocol supported by the node A1 , the node 
A1 establishes connection with the node B1 in accord- 
ance with the procedures and format defined by a DPP 

15 protocol shown in Fig. 37, and starts transferring appli- 
cation data. As shown in ®of Fig. 37, the node A1 writes 
{(bus ID of bus B), (node ID of node B1 ), (storage com- 
mand)} in the NOTIFY_BUS_RESET register of the por- 
tal A of the 1394 bridge A 3401, and transmits a con- 

20 nection request shown in ©of Fig. 37 to the node B1. In 
response to this, as shown in ®of Fig. 37, the node B1 
writes {(bus ID of bus A), (node ID of node A1), (storage 
command)} in the NOTIFY_BUS_RESET register of the 
portal B of the second 1394 bridge in accordance with 

25 the format of Fig. 31 , and transmits a connection request 
shown in @of Fig. 37 to the node A1 . 
[0285] The bus reset managers of the 1394 bridges 
A3401 and B3402 store these bus IDs and node IDs in 
corresponding storage tables. 

30 [0286] Similarly, the node B2 as a digital video cam 
coder having an AV/C protocol as an upper protocol 
starts exchanging an AV/C command with the node A2 
via the 1394 bridges A 3401 and B 3402 using an AV/C 
protocol. The node B2 performs the same write opera- 

35 tion as ®of Fig. 37 in the second 1 394 bridge in ®of 
Fig. 38 so as to enable notifying a partner node of bus 
reset. Subsequently, the node B2 issues an AV/C com- 
mand, as shown in@of Fig. 38, and enters a response 
wait state. 

40 [0287] The node A2 which has received the command 
from the node B2 performs the same write operation as 
®of Fig. 38 in the first 1394 bridge so as to enable no- 
tifying a partner node of bus reset, as shown in@of Fig. 
38. 

45 [0288] Assume that a device node A3 (3409 in Fig. 
36) is newly connected to the bus A by user operation 
in this network state. Since the new node is additionally 
connected, bus reset occurs in accordance with IEEE 
1394 characteristics. The 1394 interface layer of each 

50 node on the bus A which has received a bus reset signal 
notifies the upper protocol layer of this information. At 
the same time, the node starts a series of bus reset 
resume processes such as a bus reset sequence and 
node ID determination sequence in order to automati- 

55 cally assign a node ID upon occurrence of bus reset. 
[0289] In the fourth embodiment, as well as the first 
embodiment, the 1394 bridge A 3401 which has re- 
ceived a bus reset signal upon occurrence of bus reset 
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on the bus A executes bus reset processing on the node 
controller side of the portal A connected to the bus A. 
The bus reset manager uses a 1394 write transaction 
to sequentially write packets containing data of the bus 
ID of a remote bus, i.e., the bus ID: 3FDh of the bus A 
suffering bus reset in accordance with the register for- 
mat in REMOTE_BUS_RESET registers arranged at 
address 0240 of respective nodes stored in the storage 
tables, as shown in ©of Fig. 37 or@of Fig. 38. 
[0290] These packets are transmitted to the node on 
the bus B via the bus C and the 1394 bridge B 3402. 
[0291] Although no bus reset occurs on the bus B, the 
bus B is notified of occurrence of bus reset on the remote 
bus A by writing the ID of the bus A in the 
REMOTE. BUS_ RESET register of each node which 
should be notified to the storage table of the 1 394 bridge 
B 3402. 

[0292] The 1394 interface layer of each node which 
has detected write in the REMOTE_BUS_RESET reg- 
ister notifies the upper protocol layer of occurrence of 
bus reset on the remote bus and bus ID information of 
the remote bus. 

[0293] Similar to the first embodiment, each node per- 
forms processing corresponding to bus reset to ensure 
the consistency of an upper protocol, as shown in ©and 
©of Fig. 37 or ©and ©of Fig. 38. 
[0294] Bus reset on the bus B can also be notified 
from the 1394 bridge B 3402 to the node on the bus A 
via the bus C and 1394 bridge A 3401, thereby main- 
taining the consistency of an upper protocol. 
[0295] As described above, according to the fourth 
embodiment, a notification packet is transmitted to only 
a node to which bus reset must be notified. The traffic 
on the network does not greatly increase, and the per- 
formance of the network does not decrease. 
[0296] The fourth embodiment provides an informa- 
tion communication system including a first IEEE 1394 
bus connected to an IEEE 1 394 bridge, a first node con- 
nected to the first IEEE 1394 bus, a second IEEE 1394 
bus different from the first IEEE 1394 bus, and a second 
node connected to the second IEEE 1394 bus, the first 
and second nodes communicating with each other, 
characterized in that the second node instructs the IEEE 
1394 bridge connected to the first IEEE 1394 bus to 
monitor bus reset on the first IEEE 1394 bus and notify 
the second node of bus reset on the first IEEE 1394 bus. 
This information communication system can notify the 
self node connected to a remote bus of occurrence of 
bus reset on a bus connected to a connection partner. 
Since the self node comprises an ability of maintaining 
consistency against bus reset on the remote bus, the 
node can communicate with a conventional device 
which is connected to the remote bus and to which the 
present invention is not applied. 

[Fifth Embodiment] 

[0297] In the fifth embodiment, the same reference 



numerals as in the second embodiment denote the 
same parts of the configuration and connection device 
in the fifth embodiment, and a detailed description there- 
of will be omitted. 

5 [0298] In the fifth embodiment, similar to the first em- 
bodiment, the 1394 serial bus interface has the same 
arrangement as in the first embodiment shown in Fig. 
23, and the configuration ROM of each node has the 
same format as shown in Figs. 24 and 25. Further, an 

10 IEEE 1394 bridge device 101 has the same arrange- 
ment as in the second embodiment shown in Fig. 32. 
[0299] The fifth embodiment is different from the 
above embodiments in that the format of an area where 
serial bus dependent registers from address 0200 to ad- 

*5 dress 0400 shown in Fig. 25 has the format shown in 
Fig. 39. 

[0300] The fifth embodiment uses address 023C, and 
does not require an area from address 0240, compared 
to the serial bus dependent registers shown in Figs. 26 

20 and 30. That is, the fifth embodiment is characterized 
by an operation with defined registers at address 0200 
to address 0230 described in <Technical Overview of 
IEEE 1394 Standards The operation in the fifth embod- 
iment adopting the 1394 bridge 101 with the same ar- 

25 rangement shown in Fig. 32 as the second embodiment 
will be described with reference to Figs. 40 and 41 . 
[0301] Fig. 40 is a view showing communication con- 
trol procedures complying with a direct print protocol (to 
be referred to as a "DPP" hereinafter) in the fifth embod- 

30 iment according to the present invention. Fig. 41 is a 
view showing communication control procedures com- 
plying with an AV/C protocol in the fifth embodiment. 
[0302] Before buses A and B attain their current con- 
nection configurations, bus reset independently occurs 

35 on each bus every time a device node is additionally 
connected. A bus reset sequence and bus ID determi- 
nation sequence are executed to automatically assign 
a node ID upon occurrence of bus reset, and a new to- 
pology is created. 

40 [0303] Then, 1394 data transfer starts on each bus. 
Details of these sequences are described in "(6) De- 
scription of Sequence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technica I Overview 
of IEEE 1394 Standards and a description thereof will 

45 be omitted. 

[0304] Although the operation changes depending on 
the connection order of connection nodes and the con- 
nection order of buses to the 1 394 bridge, the bus reset- 
1394 initialization sequence is repeated every time a 

so node is connected. Finally, a topology in which devices 
A1 and A2 are connected to the bus A via the 1394 
bridge 101 , and devices B1 and B2 are connected to the 
bus B is formed. 

[0305] While the topology of the 1394 network is de- 
55 termined in this state, and 1 394 data transfer is normally 
performed, the node A1 as a digital still camera having 
a DPP as an upper protocol searches for a printer device 
which supports the DPP on the 1394 network, like the 
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self node, in order to transfer image data to a printer 
connected to the 1394 network and print the image data 
in accordance with user operation or the trigger of an 
application. 

[0306] This is realized by read-accessing the config- 5 
uration ROM of a partner node for a node connected to 
the network. This is described in the first embodiment 
with reference to Fig. 19. More specifically, the node us- 
es an IEEE 1394 read transaction for the partner node 
to receive the ROM contents of the partner node as a w 
read response. 

[0307] As described above, 1 394-related information 
is described in the configuration ROM of each node. Fur- 
ther, the basic function of each node such as a printer 
or camera is described in the instance directory, and an is 
upper protocol such as an AV/C protocol or DPP and 
software information are described in the unit directory. 
[0308] While the node A1 read-accesses the ROM of 
each node on the local bus A, and then read-accesses 
the ROM of each node on the bus B via the 1 394 bridge, 20 
the node A1 detects that the node B1 is a printer as a 
DPP device. 

[0309] Although details of a 1394 transaction via the 
1 394 bridge will be omitted, its standard is being defined 
by IEEEp1394.1. 25 
[031 0] After the camera as the node A1 finds the node 
B1 which is a printer and has the same protocol as the 
DPP protocol shown in Fig. 40 that is supported by the 
node A1 , the node A1 establishes connection with the 
node B1 in accordance with procedures and a format 30 
defined by the DPP protocol. 

[031 1] More specifically, the node A1 transmits a con- 
nection request command to the node B1 using a write 
transaction, as shown in ®of Fig. 40. In response to 
this, the node B1 transmits a connection request re- 35 
sponse shown in d)of Fig. 40 to the node A1 . 
[0312] At this time, the 1394 bridge 101 traces com- 
munication between these nodes, and stores an identi- 
fication set of the bus ID and node ID of the node B1 , 
those of the node A1, and the DPP protocol in a con- 40 
nection management table 3105. 
[0313] Similarly, the node B2 as a digital video cam 
coder having an AV/C protocol as an upper protocol 
starts transmission/reception of an AV/C command with 
the node A2 shown in Fig. 41 via the 1 394 bridge using 45 
an AV/C protocol. The node B2 issues an AV/C com- 
mand shown in ®of Fig. 41 , and enters a response wait 
state. 

[0314] The 1394 bridge 101 traces communication 
between these nodes, and stores an identification set of 50 
the bus ID and node ID of the node B2, those of the node 
A2, and the AV/C protocol in the connection manage- 
ment table 3105. 

[0315] Assume that a device node A3 (node 108 
shown in Fig. 1 ) is newly connected to the bus A by user 55 
operation in this network state. Then, bus reset occurs, 
as described above, and a series of bus reset resume 
processes start. When bus reset on the bus A is notified 



to the DPP layer, the node A1, which has established 
connection with the node B1 on the bus B in accordance 
with a DPP protocol on the bus A and has performed 
data transfer, starts the above-described bus reset 
resume processing complying with the DPP protocol. 
[0316] On the bus B whose connection configuration 
is not changed, no bus reset occurs. If bus reset occurs 
on the bus A connected via the 1 394 bridge 1 01 , the bus 
B detects this, but the characteristics of the 1394 bridge 
101 in the fifth embodiment prevent any bus reset signal 
from propagating to another bus, i.e., the bus B in this 
case. 

[0317] Hence, only nodes such as the nodes A1 , A2, 
and A3 connected to the bus A start bus reset resume 
processing. The node B1 as the data transmission des- 
tination of the node A1 and the node B2 as the data 
transmission destination of the node A2 do not start this 
processing. 

[031 8] In the 1 394 network system of the fifth embod- 
iment, the 1394 bridge 101 comprises a means for stor- 
ing connection information containing the upper proto- 
col of a node which establishes connection via the 
bridge, and performing, by the bridge, bus reset resume 
processing of the upper protocol layer which should be 
executed by a node connected to the other node upon < 
occurrence of bus reset on one bus. 
[0319] More specifically, the 1394 bridge 101 which 
has received a bus reset signal upon occurrence of bus 
reset on the bus A executes bus reset processing on the 
node controller side connected to the bus A. At the same 
time, the 1394 bridge 101 confirms a node on the bus 
A which starts bus reset resume processing of the upper 
protocol layer, from connection information stored in the 
connection management table. 
[0320] The node A1 of the bus A transmits a recon- 
nection command shown in @of Fig. 40 to the node B1 
with which the node A1 establishes connection to trans- 
fer data. The 1394 bridge does not transmit this to the 
node B1, but transmits a reconnection response shown 
in@of Fig. 40 to the node A1 in place of the node B1. 
This ensures the consistency of DPP protocol process- 
ing between the node A1 which starts bus reset process- 
ing after bus reset actually occurs, and the node B1 con- 
nected to the bus B on which no bus reset occurs. 
[0321] The node B2, which has exchanged an AV/C 
command with the node A2 on the bus A in accordance 
with an AV/C protocol on the bus B, wait for a response 
from the node A2. However, the communication desti- 
nation node A2 starts bus reset processing complying 
with an AV/C protocol, and abandons the command re- 
ceived from the node B2 because bus reset has oc- 
curred on the connected bus A. The 1394 bridge knows 
that a response from the node A2 is not transmitted to 
the node B2. Thus, the 1394 bridge resends an AV/C 
command which the node B2 sent before remote bus 
reset and for which no response is received, to the node 
A2 f as shown in ©of Fig. 41. 

[0322] This ensures the consistency of AV/C protocol 
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processing between the node A2 which starts bus reset 
processing after bus reset actually occurs, and the node 
B2 connected to the bus B on which no bus reset occurs. 
Thus, subsequent communication control procedures 
can be smoothly executed, as shown in, e.g.,(3)of Fig. 
41. 

[0323] As described above, the fifth embodiment pro- 
vides an information communication system including a 
first IEEE 1394 bus connected to an IEEE 1394 bridge, 
a first node connected to the first IEEE 1 394 bus, a sec- 
ond IEEE 1394 bus different from the first IEEE 1394 
bus, and a second node connected to the second IEEE 
1394 bus, the first and second nodes communicating 
with each other, characterized in that the IEEE 1394 
bridge comprises a means for interpreting an upper pro- 
tocol used by communication between the first and sec- 
ond nodes, and a means for performing processing 
which should be done by the second node, by the bridge 
instead of the second node when bus reset occurs on 
the first IEEE 1394 bus, and when bus reset occurs on 
the first IEEE 1394 bus, the IEEE bus bridge performs 
processing which should be executed upon occurrence 
of bus reset between the first node and the IEEE 1394 
bridge, thereby performing communication between the 
first and second nodes regardless of bus reset on the 
first IEEE 1394 bus. 

[0324] According to the fifth embodiment, if bus reset 
occurs on one local bus in performing data transfer from 
a data transmission node on one local bus to a data re- 
ception node connected to the other local bus via a 1 394 
bridge using the same upper protocol, the 1394 bridge 
101 can execute bus reset resume processing instead 
of the node on the remote bus. 
[0325] As a result, the consistency of bus reset 
processing in the upper protocol layer can be main- 
tained without notifying the reception node connected 
to the other bus of occurrence of bus reset. This realizes 
normal data communication between buses. 
[0326] More specifically, in a system in which a plu- 
rality of communication control networks (e.g., IEEE 
1394 buses) are connected via connection devices (e. 
g., IEEE 1394 bridges), if a network configuration up- 
date request (e.g., IEEE 1394 bus reset) occurs in one 
communication control network in performing data 
transfer from a data transmission communication device 
of one communication network to a data reception com- 
munication device connected to the other communica- 
tion control network via a connection device using the 
same upper protocol, the connection device can exe- 
cute network configuration update resume processing 
instead of the communication device connected to the 
communication control network. The consistency of net- 
work configuration update request processing in the up- 
per protocol layer can be ensured without notifying the 
reception communication device connected to the other 
communication control network of the network configu- 
ration update request. This enables normal data com- 
munication between communication control networks. 



[Other Embodiment] 

[0327] The present invention may be applied to a sys- 
tem constituted by a plurality of devices (e.g., a host 
5 computer, interface device, reader, and printer) or an ap- 
paratus comprising a single device (e.g., a copying ma- 
chine or facsimile apparatus). 
[0328] The object of the present invention is realized 
even by supplying a storage medium storing software 
program codes for realizing the functions of the above- 
described embodiments to a system or apparatus, and 
causing the computer (or a CPU or MPU) of the system 
or apparatus to read out and execute the program codes 
stored in the storage medium. 
[0329] In this case, the program codes read out from 
the storage medium realize the functions of the above- 
described embodiments by themselves, and the storage 
medium storing the program codes constitutes the 
present invention. 

[0330] As a storage medium for supplying the pro- 
gram codes, a floppy disk, hard disk, optical disk, mag- 
netooptical disk, CD-ROM, CD-R, magnetic tape, non- 
volatile memory card, ROM, or the like can be used. 
[0331] The functions of the above-described embod- 
iments are realized not only when the readout program 
codes are executed by the computer but also when the 
OS (Operating System) running on the computer per- 
forms part or all of actual processing on the basis of the 
instructions of the program codes. 
[0332] The functions of the above-described embod- 
iments are also realized when the program codes read 
out from the storage medium are written in the memory 
of a function expansion board inserted into the computer 
or a function expansion unit connected to the computer, 
and the CPU of the function expansion board or function 
expansion unit performs part or all of actual processing 
on the basis of the instructions of the program codes. 
[0333] When the present invention is applied to the 
above storage medium, program codes corresponding 
to the above-described flow charts are stored in this 
storage medium. 

[0334] As many apparently widely different embodi- 
ments of the present invention can be made without de- 
parting from the spirit and scope thereof, it is to be un- 
derstood that the invention is not limited to the specific 
embodiments thereof except as defined in the append- 
ed claims. 



Claims 

1. An information signal processing apparatus con- 
nected to a communication control network, char- 
acterized by comprising: 

reset reception means for, upon issuing an 
update request when a network configuration must 
be updated in a remote network other than the com- 
munication control network connected to the infor- 
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mation signal processing apparatus, receiving net- 
work specifying information for the issued update 
request, and a network update notification. 

2. The apparatus according to claim 1 , characterized 5 
in that said reset reception means uses a predeter- 
mined address as a register, detects write of the net- 
work specifying information at the address, and re- 
ceives a network update occurrence notification of 
the remote network. 10 

3. The apparatus according to claim 1 , characterized 
in that the communication control network includes 
a communication control bus complying with IEEE 
1394. is 



ed via a communication control bus complying with 
IEEE 1394, characterized by comprising the step 
of: 

notifying occurrence of remote bus reset 
when a plurality of buses are connected via a 
bridge, and bus reset occurs on a remote bus other 
than a connected bus. 

10. The method according to claim 9, characterized in 
that a bridge connected to a bus on which bus reset 
occurs notifies an information signal processing ap- 
paratus connected to another connected bus of a 
remote bus reset occurrence notification containing 
bus specifying information for occurrence of bus re- 
set. 



4. The apparatus according to claim 3, characterized 
in that a predetermined register is arranged in a 
core CSR architecture register space in an address 
space of the information signal processing appara- 20 
tus connected to each communication control bus 
complying with IEEE 1394. 

5. The apparatus according to claim 3, characterized 

in that a predetermined register is arranged in a se- 25 
rial bus register space in an address space of the 
information signal processing apparatus connected 
to each communication control bus complying with 
IEEE 1394. 

30 

6. An information signal processing method in an 
IEEE 1394 bus system in which a plurality of infor- 
mation signal processing apparatuses are connect- 
ed via a communication control network, charac- 
terized by comprising: 35 

the step of, upon issuing an update request 
when a network configuration must be updated in a 
remote network other than the communication con- 
trol network connected to the information signal 
processing apparatuses, receiving network sped- 4 ® 
fying information for the issued update request, and 
a network update notification. 



11. An information communication system connectable 
to a serial bus via a serial bridge, characterized in 
that 

the serial bridge comprises: 

at least two portals respectively connected to 
different serial buses; 

a registration table for registering serial bus 
specifying information and information of a con- 
nected node for each connected serial bus; 
monitoring means for monitoring bus reset on 
the serial bus connected to each portal; and 
re-registration means for, when said monitoring 
means detects bus reset, rewriting contents of 
the registration table corresponding to the se- 
rial bus on which bus reset is detected in ac- 
cordance with newly updated node information, 
and 

a change in system configuration can be rec- 
ognized by updating the registration table. 

12. The system according to claim 11, characterized 
in that the serial bus specifying information in- 
cludes a bus ID assigned to each bus, and the node 
information includes a node ID assigned to each 
node. 



20 



7. The method according to claim 6, characterized by 
further comprising the step of using a predeter- 45 
mined address as a register, detecting write of the 
network specifying information at the address, and 
receiving a network update occurrence notification 

of the remote network. 

so 

8. The method according to claim 6, characterized in 
that the communication control network includes a 
communication control bus complying with IEEE 
1394. 

55 

9. An information signal processing method in an 
IEEE 1394 bus system in which a plurality of infor- 
mation signal processing apparatuses are connect- 



13. The system according to claim 12, characterized 
in that the registration table registers, for each bus, 
all node IDs connected to the bus in association with 
a bus ID. 

14. The system according to claim 11, characterized 
in that 

the serial bridge further comprises communica- 
tion management means for managing a com- 
munication state of a node connected to the 
connected serial bus, and 
when said monitoring means detects bus reset, 
said monitoring means notifies, of re-registra- 
tion, a node rewritten by said re-registration 
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means and a node having a communication 
state managed by said communication man- 
agement means. 

15. The system according to claim 14, characterized 5 
in that 



16. The system according to claim 15, characterized 
in that 

the system further comprises confirmation 20 
means capable of confirming occurrence of bus 
reset on a bus connected to the communication 
partner node from the node connected to the 
serial bus, and 

if a node written when said re-registration 25 
means detects rewrite of the re-registration ta- 
ble in correspondence with detection of bus re- 
set by said monitoring means corresponds to 
the node having the communication state man- 
aged by said communication management 30 
means, said confirmation means rewrites node 
information of said communication manage- 
ment means in correspondence with re-regis- 
tration, thereby enabling confirming occurrence 
of bus reset on the bus connected to the com- 35 
munication partner node. 

17. The system according to claim 11, characterized 
in that the serial bridge comprises: 

40 

notification request reception means for receiv- 
ing a notification request to a communication 
partner node from a node connected to a bus 
on which bus reset has occurred; and 
notification means for notifying the communica- 45 
tion partner node in accordance with the notifi- 
cation request from said notification request re- 
ception means. 

18. The system according to claim 11, characterized 50 
in that the serial bus includes an IEEE 1394 bus 
complying with IEEE 1394, and the serial bridge in- 
cludes an IEEE 1394 bridge complying with IEEE 
1394. 

55 

19. An information communication method in an infor- 
mation communication system connectable via a 
serial bridge having portals respectively connected 



to different serial buses and a registration table for 
registering node information, characterized by 
comprising the steps of: 

registering information of a connected node 
in addition to serial bus specifying information in the 
registration table for each serial bus connected to 
the serial bridge, monitoring bus reset on the serial 
bus connected to each portal, when bus reset is de- 
tected, rewriting, in accordance with newly updated 
node information, contents of the registration table 
corresponding to a serial bus on which bus reset is 
detected, and updating the registration table, there- 
by enabling recognizing a change in system config- 
uration. 

20. The method according to claim 19, characterized 
in that the serial bus specifying information in- 
cludes a bus ID assigned to each bus, and the node 
information includes a node ID assigned to each 
node. 

21. The method according to claim 20, characterized 
in that the registration table registers, for each bus, 
all node IDs connected to the bus in association with 
a bus ID. 

22. The method according to claim 19, characterized 
by further comprising the step of, when the serial 
bus detects a bus reset, notifying a node, which 
communicates with a node connected to the serial 
bus on which the bus reset is detected, of the bus 
reset on the bus connected to the communication 
partner node. 

23. The method according to claim 22, characterized 
in that the node connected to the serial bus regis- 
ters a node communication state capable of speci- 
fying a communication partner in a serial bridge cor- 
responding to the bus during communication with 
another node, thereby enabling managing the node 
communication state. 

24. The method according to claim 23, characterized 
in that the serial bridge rewrites, in accordance with 
a state after bus reset, a registration communication 
state of the node which communicates with the 
node connected to the bus on which a bus reset has 
occurred, thereby enabling the connected node to 
confirm occurrence of the bus reset on the bus con- 
nected to the communication partner node. 

25. The method according to claim 19, characterized 
in that the serial bus includes an IEEE 1394 bus 
complying with IEEE 1394, and the serial bridge in- 
cludes an IEEE 1394 bridge complying with IEEE 
1394. 

26. An information communication system having a first 



said communication management means com- 
prises a communication state write portion in 
which a node communication state can be writ- 10 
ten for each node connected to the bus, and 
said communication management means man- 
ages the node communication state by writing 
information of a communication partner node in 
the communication state write portion. 15 
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communication control network capable of connect- 
ing communication devices via a serial bus, a sec- 
ond communication network capable of connecting 
communication devices via a serial bus different 
from the serial bus of the first communication con- 
trol network, and a connection device for enabling 
communication between the first and second com- 
munication control networks, characterized in that 
the connection device comprises: 

interpretation means for interpreting an upper 
protocol used by communication between a 
first communication device connected to the 
first communication control network and a sec- 
ond communication device connected to the 
second communication control network; and 
proxy means for performing, instead of the sec- 
ond communication device, processing which 
should be performed by the second communi- 
cation device when a network configuration 
must be updated in the first communication 
control network, and 

the first and second communication devices 
can communicate with each other regardless of 
a network update request in the first communi- 
cation control network. 

27. The system according to claim 26, characterized 
in that the serial bus includes a communication 
control bus complying with IEEE 1394, and the con- 
nection device includes an IEEE 1394 bridge com- 
plying with IEEE 1394. 

28. An information communication system including a 
first serial bus connected to a connection device, a 
first node connected to the first serial bus, a second 
serial bus different from the first serial bus, and a 
second node .connected to the second serial bus, 
the first and second nodes being able to communi- 
cate with each other, characterized in that 

the connection device comprises: 

interpretation means for interpreting an upper 
protocol used by communication between the 
first and second nodes; and 
proxy means for performing, instead of the sec- 
ond node, processing which should be per- 
formed by the second node when bus reset oc- 
curs on the first serial bus, and 
when bus reset occurs on the first serial bus, 
the connection device performs processing 
which should be performed upon occurrence of 
bus reset between the first node and the con- 
nection device, thereby performing communi- 
cation between the first and second nodes re- 
gardless of bus reset on the first serial bus. 

29. The system according to claim 28, characterized 



in that the serial bus includes a communication 
control bus complying with IEEE 1394, and the con- 
nection device includes an IEEE 1394 bridge com- 
plying with IEEE 1394. 

5 

30. An information communication method in an infor- 
mation communication system having a first com- 
munication control network capable of connecting 
communication devices via a serial bus, a second 

10 communication network capable of connecting 
communication devices via a serial bus different 
from the serial bus of the first communication con- 
trol network, and a connection device for enabling 
communication between the first and second corn- 
's munication control networks, characterized in that 
the connection device interprets an upper pro- 
tocol used by communication between a first com- 
munication device connected to the first communi- 
cation control network and a second communica- 
20 tion device connected to the second communica- 
tion control network, and performs, instead of the 
second communication device, processing which 
should be performed by the second communication 
device when a network configuration must be up- 
25 dated in the first communication control network, 
thereby enabling communication between the first 
and second communication devices regardless of 
a network update request in the first communication 
control network. 

30 

31. The method according to claim 30, wherein the se- 
rial bus includes a communication control bus com- 
plying with IEEE 1394, and the connection device 
includes an IEEE 1394 bridge complying with IEEE 

35 1394. 

32. A computer-readable storage medium which stores 
a computer program for realizing a reset reception 
function of, upon issuing an update request when a 

40 network configuration must be updated in a remote 
network other than a communication control net- 
work connected to an information signal processing 
apparatus connected to the communication control 
network, receiving network specifying information 
45 for the issued update request, and a network update 
notification. 

33. The medium according to claim 32, characterized 
in that the reset reception function uses a prede- 

50 termined address as a register, detects write of the 
network specifying information at the address, and 
receives a network update occurrence notification 
of the remote network. 

55 34. A computer-readable storage medium incorporated 
in a bridge that realizes a function of, when a plu- 
rality of buses of IEEE 1 394 bus systems connected 
to a plurality of information signal processing appa- 
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ratuses via communication control buses complying 
with IEEE 1394 are connected via bridges, and bus 
reset occurs on a remote bus other than the con- 
nected buses, notifying information signal process- 
ing apparatuses connected to other buses connect- 
ed via bridges connected to the buses of occur- 
rence of remote bus reset containing bus specifying 
information for occurrence of the bus reset. 

35. A computer-readable storage medium incorporated 
in a connection device of an information communi- 
cation system having a first communication control 
network capable of connecting communication de- 
vices via a serial bus, a second communication net- 
work capable of connecting communication devices 
via a serial bus different from the serial bus of the 
first communication control network, and the con- 
nection device for enabling communication be- 
tween the first and second communication control 
networks, wherein said medium stores computer 
program streams for realizing an interpretation 
function of interpreting an upper protocol used by 
communication between a first communication de- 
vice connected to the first communication control 
network and a second communication device con- 
nected to the second communication control net- 
work, and a proxy function of performing, instead of 
the second communication device, processing 
which should be performed by the second commu- 
nication device when a network configuration must 
be updated in the first communication control net- 
work, and for realizing communication between the 
first and second communication devices regardless 
of a network update request in the first communica- 
tion control network. 

36. A computer-readable storage medium incorporated 
in a connection device of an information communi- 
cation system including a first serial bus connected 
to the connection device, a first node connected to 
the first serial bus, a second serial bus different from 
the first serial bus, and a second node connected 
to the second serial bus, the first and second nodes 
being able to communicate with each other, wherein 
said medium stores computer program streams for 
realizing an interpretation function of interpreting an 
upper protocol used by communication between the 
first and second nodes, and a proxy function of per- 
forming, instead of the second node, processing 
which should be performed by the second node 
when bus reset occurs on the first serial bus, and 
for enabling communication between communica- 
tion between the first and second nodes regardless 
of bus reset on the first serial bus by performing 
processing which should be performed upon occur- 
rence of bus reset between the first node and the 
connection device when bus reset occurs on the 
first serial bus. 



37. A computer-readable storage medium incorporated 
in a connection device of an information communi- 
cation system having a first communication control 
network capable of connecting communication de- 

5 vices via a serial bus, a second communication net- 
work capable of connecting communication devices 
via a serial bus different from the serial bus of the 
first communication control network, and a connec- 
tion device for enabling communication between 

10 the first and second communication control net- 
works, wherein said medium stores computer pro- 
gram streams for interpreting an upper protocol 
used by communication between a first communi- 
cation device connected to the first communication 

15 control network and a second communication de- 
vice connected to the second communication con- 
trol network, and performing, instead of the second 
communication device, processing which should be 
performed by the second communication device 

20 when a network configuration must be updated in 
the first communication control network, thereby 
enabling communication between the first and sec- 
ond communication devices regardless of a net- 
work update request in the first communication con- 

25 trol network. 

38. A serial bus bridge having at least two portals re- 
spectively connected to different serial buses, 
wherein each of said portals characterized by 

30 comprising: 

detecting means for detecting a bus reset of a 
serial bus to which the portal is connected; 
storage means for storing ID information des- 
35 ignating a node on a network which comprises 

a plurality of serial buses, including serial buses 
to which said portals are connected, intercon- 
nected via serial bus bridge(s); 
receiving means for receiving a control mes- 
40 sage including the ID information designating a 

node on the network, wherein said control mes- 
sage further includes a registration command 
or a deletion command; 
wherein each of the portals stores the ID infor- 
45 mation in the control message into the storage 

means if received control message includes the 
registration command, deletes the ID informa- 
tion stored in the storage means if received 
control message includes the deletion corn- 
so mand; and 

a transmitting means for transmitting a notice 
message including a bus ID information, desig- 
nating a serial bus in which the detecting means 
detected a bus reset, to the node which is des- 
55 ignated by the ID information stored in the stor- 

age means. 

39. A terminal apparatus operable as a node on a net- 
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means detects a bus reset of the first serial bus. 

43. An information communicating system, wherein 
communication is performed between a first termi- 

5 nal apparatus operable as a first node connected to 
a first serial bus included in a network comprising a 
plurality of serial buses connected via serial bus 
bridge(s), and a second terminal apparatus opera- 
ble as a second node connected to a second serial 

10 bus which is different from said first serial bus, char- 
acterized in that 

the second serial bus is connected to a serial 
bus bridge according to claim 38; 

15 the first terminal apparatus is a terminal appa- 

ratus according to claim 39 and claim 40; 
the first terminal apparatus transmits, when it 
starts communicating, a control message in- 
cluding an ID information, designating the first 

20 node and the registration command, to a portal 

connected to the second serial bus within por- 
tals of the serial bus bridge, and transmits, 
when it terminates communicating, a control 
message including an ID information, designat- 

25 ing the first node and the deletion command, to 

a portal connected to the second serial bus 
within portals of the serial bus bridge; and 
the portal, during the communication between 
the first and the second terminal apparatus, 

30 stores the ID information designating the first 

node into the storage means, and transmits a 
notice message including a bus ID information 
designating the second serial bus to the first 
terminal apparatus when the detecting means 

35 detects a bus reset of the second serial bus. 

44. A serial bus bridge according to claim 38, charac- 
terized in that the serial buses complying with 
IEEE 1394. 

40 

45. A terminal apparatus according to claim 39, char- 
acterized in that the serial buses complying with 
IEEE 1394. 



work which comprises a plurality of serial buses in- 
terconnected via serial bus bridge(s), character- 
ized in that said terminal apparatus transmits said 
control message, including an ID information which 
designates a node on the network, to the portal of 
the serial bus bridge according to claim 38. 

40. A terminal apparatus operable as a node on a net- 
work which comprises a plurality of serial buses in- 
terconnected via serial bus bridge(s), character- 
ized by said terminal apparatus receives a control 
message, including bus ID information which des- 
ignates a serial bus, from the portal of the serial bus 
bridge according to claim 38. 

41. An information communicating system character- 
ized by comprising: 

a network comprising a plurality of serial buses 
interconnected via serial bus bridge(s); 
a serial bus bridge according to claim 38; 
a terminal apparatus according to claim 39; and 
a terminal apparatus according to claim 40. 

42. An information communicating system, wherein • 
communication is performed between a first termi- 
nal apparatus operable as a first node connected to 
a first serial bus included in a network comprising a 
plurality of serial buses connected via serial bus 
bridge(s), and a second terminal apparatus opera- 
ble as a second node connected to a second serial 
bus which is different from said first serial bus, char- 
acterized in that 

the first serial bus is connected to a serial bus 
bridge according to claim 38; 
the first terminal apparatus is a terminal appa- 
ratus according to claim 39; 
the second terminal apparatus is a terminal ap- 
paratus according to claim 40; 
the first terminal apparatus transmits, when it 
starts communicating, a control message in- 
cluding an ID information, designating the sec- 
ond node and the registration command, to a 
portal connected to the first serial bus within 
portals of the serial bus bridge, and transmits, 
when it terminates communicating, a control 
message including an ID information, designat- 
ing the second node and the deletion com- 
mand, to a portal connected to the first serial 
bus within portals of the serial bus bridge; and 
the portal, during the communication between 
the first and the second terminal apparatus, 
stores the ID information designating the sec- 
ond node into the storage means, and transmits 
a notice message including a bus ID informa- 
tion designating the first serial bus to the sec- 
ond terminal apparatus when the detecting 



45 46. A terminal apparatus according to claim 40, char- 
acterized in that the serial buses complying with 
IEEE 1394. 

47. An information communicating system according to 
50 any one of claims 41 to 43, characterized by the 

serial buses complying with IEEE 1394. 

48. An information communicating method of an infor- 
mation communicating system, wherein communi- 

55 cation is performed between a first terminal appa- 
ratus operable as a first node connected to a first 
serial bus included in a network comprising a plu- 
rality of serial buses connected via serial bus bridge 
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56 



49. 



(s), and a second terminal apparatus operable as a 
second node connected to a second serial bus 
which is different from said first serial bus, charac- 
terized in that 

the first serial bus is connected to a serial bus 
bridge according to claim 38; 
the first terminal apparatus is a terminal appa- 
ratus according to claim 39; 
the second terminal apparatus is a terminal ap- 
paratus according to claim 40; 
wherein said method comprising the steps of: 

a step wherein the first terminal apparatus 
transmitting, when it starts communicating, a 
control message including an ID information, 
designating the second node and the registra- 
tion command, to a portal connected to the first 
serial bus within portals of the serial bus bridge; 
a step wherein the first terminal apparatus 
transmitting, when it terminates communicat- 
ing, a control message including an ID informa- 
tion, designating the second node and the de- 
letion command, to a portal connected to the 
first serial bus within portals of the serial bus 
bridge; and 

a step wherein the portal, during the communi- 
cation between the first and the second termi- 
nal apparatus, storing the ID information des- 
ignating the second node into the storage 
means, and transmitting a notice message in- 
cluding a bus ID information designating the 
first serial bus to the second terminal apparatus 
when the detecting means detects a bus reset 
of the first serial bus. 

An information communicating method of an infor- 
mation communicating system, wherein communi- 
cation is performed between a first terminal appa- 
ratus operable as a first node connected to a first 
serial bus included in a network comprising a plu- 
rality of serial buses connected via serial bus bridge 
(s), and a second terminal apparatus operable as a 
second node connected to a second serial bus 
which is different from said first serial bus, charac- 
terized in that 
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to the second serial bus within portals of 
the serial bus bridge; 

a step wherein the first terminal apparatus 
transmitting, when it terminates communi- 
cating, a control message including an ID 
information, designating the first node and 
the deletion command, to a portal connect- 
ed to the second serial bus within portals 
of the serial bus bridge; and 
a step wherein the portal, during the com- 
munication between the first and the sec- 
ond terminal apparatus, storing the ID in- 
formation designating the first node into the 
storage means, and transmitting a notice 
message including a bus ID information 
designating the second serial bus to the 
first terminal apparatus when the detecting 
means detects a bus reset of the second 
serial bus. 

50. An information communication system connectable 
to a serial bus via a serial bridge, characterized in 
that 

the serial bridge comprises: 

at least two portals respectively connected to 
different serial buses; 

a registration table for registering serial bus 
designating information and information of a 
connected node for each connected serial bus; 
monitoring means for monitoring bus reset on 
the serial bus connected to each portal; and 
re-registration means for, when said monitoring 
means detects bus reset, rewriting contents of 
the registration table corresponding to the se- 
rial bus on which bus reset is detected in ac- 
cordance with newly updated node information, 
and 

a change in system configuration can be rec- 
ognized by updating the registration table. 

51 . The system according to claim 50, characterized 
in that the serial bus designating information in- 
cludes a bus ID assigned to each bus, and the node 
information includes a node ID assigned to each 
node. 



the second serial bus is connected to a serial 

bus bridge according to claim 38; 

the first terminal apparatus is a terminal appa- so 

ratus according to claims 39 and 40; 

wherein said method comprising the steps of: 

a step wherein the first terminal apparatus 
transmitting, when it starts communicating, 55 
a control message including an ID informa- 
tion, designating the first node and the reg- 
istration command, to a portal connected 



52. The system according to claim 51 , characterized 
in that the registration table registers, for each bus, 
all node IDs connected to the bus in association with 
a bus ID. 

53. The system according to any one of claims 50 to 
52, characterized in that 

the serial bridge further comprises communica- 
tion management means for managing a com- 
munication state of a node connected to the 
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58 



connected serial bus, and 
when said monitoring means detects bus reset, 
said monitoring means notifies, of re-registra- 
tion, a node rewritten by said re-registration 
means and a node having a communication 5 
state managed by said communication man- 
agement means. 

54. The system according to claim 53, characterized 

in that 10 

said communication management means com- 
prises a communication state write portion in 
which a node communication state can be writ- 
ten for each node connected to the bus, and *s 
said communication management means man- 
ages the node communication state by writing 
information of a communication partner node in 
the communication state write portion. 

20 

55. The system according to claim 54, characterized 
in that 



56. The system according to any one of claims 50 to 

55, characterized in that the serial bridge compris- 
es: 

45 

notification request reception means for receiv- 
ing a notification request to a communication 
partner node from a node connected to a bus 
on which bus reset has occurred; and 
notification means for notifying the communica- so 
tion partner node in accordance with the notifi- 
cation request from said notification request re- 
ception means. 

57. The system according to any one of claims 50 to 55 

56, characterized in that the serial bus includes an 
IEEE 1394 bus complying with IEEE 1394, and the 
serial bridge includes an IEEE 1 394 bridge comply- 



ing with IEEE 1394. 

58. An information communication method in an infor- 
mation communication system connectable via a 
serial bridge having portals respectively connected 
to different serial buses and a registration table for 
registering node information, characterized by 
comprising the steps of: 

registering information of a connected node 
in addition to serial bus designating information in 
the registration table for each serial bus connected 
to the serial bridge, monitoring bus reset on the se- 
rial bus connected to each portal, when bus reset 
is detected, rewriting, in accordance with newly up- 
dated node information, contents of the registration 
table corresponding to a serial bus on which bus 
reset is detected, and updating the registration ta- 
ble, thereby enabling recognizing a change in sys- 
tem configuration. 

59. The method according to claim 58, characterized 
in that the serial bus designating information in- 
cludes a bus ID assigned to each bus, and the node 
information includes a node ID assigned to each 
node. 

60. The method according to claim 59, characterized 
in that the registration table registers, for each bus, 
all node IDs connected to the bus in association with 
a bus ID. 

61. The method according to any one of claims 58 to 
60, characterized by further comprising the step 
of, when the serial bus detects a bus reset, notifying 
a node, which communicates with a node connect- 
ed to the serial bus on which the bus reset is de- 
tected, of the bus reset on the bus connected to the 
communication partner node. 

62. The method according to claim 61, characterized 
in that the node connected to the serial bus regis- 
ters a node communication state capable of desig- 
nating a communication partner in a serial bridge 
corresponding to the bus during communication 
with another node, thereby enabling managing the 
node communication state. 

63. The method according to claim 62, characterized 
in that the serial bridge rewrites, in accordance with 
a state after bus reset, a registration communication 
state of the node which communicates with the 
node connected to the bus on which a bus reset has 
occurred, thereby enabling the connected node to 
confirm occurrence of the bus reset on the bus con- 
nected to the communication partner node. 

64. The method according to any one of claims 58 to 
63, characterized in that the serial bus includes an 



the system further comprises confirmation 
means capable of confirming occurrence of bus 25 
reset on a bus connected to the communication 
partner node from the node connected to the 
serial bus, and 

if a node written when said re-registration 
means detects rewrite of the re-registration ta- 30 
ble in correspondence with detection of bus re- 
set by said monitoring means corresponds to 
the node having the communication state man- 
aged by said communication management 
means, said confirmation means rewrites node 35 
information of said communication manage- 
ment means in correspondence with re-regis- 
tration, thereby enabling confirming occurrence 
of bus reset on the bus connected to the com- 
munication partner node. 40 
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IEEE 1394 bus complying with IEEE 1394, and the 
serial bridge includes an IEEE 1 394 bridge comply- 
ing with IEEE 1394. 

65. Computer program streams for a portal included in 
a serial bus bridge having at least two portals re- 
spectively connected to different serial buses, char- 
acterized in that said computer program streams 
enabling the portal; 



tern configuration. 

68. A computer-readable storage medium character- 
ized by storing computer program streams accord- 
5 ing to claim 67. 



detecting function of detecting a bus reset of a 
serial bus to which the portal is connected; 
storage function of storing ID information des- 
ignating a node on a network which comprises 
a plurality of serial buses, including serial buses *5 
to which said portals are connected, intercon- 
nected via serial bus bhdge(s); 
receiving function of receiving a control mes- 
sage including the ID information designating a 
node on the network, wherein said control mes- 20 
sage further includes a registration command 
or a deletion command; 
wherein the portal stores the ID information in 
the control message by the storage function if 
received control message includes the registra- 25 
tion command, deletes the ID information from 
the storage of the storage function if received 
control message includes the deletion com- 
mand; and 

a transmitting function of transmitting a notice 30 
message including a bus ID information, desig- 
nating a serial bus in which the detecting func- 
tion detected a bus reset, to the node which is 
designated by the ID information stored by the 
storage function. 35 



66. A computer-readable storage medium character- 
ized by storing computer program streams accord- 
ing to claim 65. 

40 

67. Computer program streams for an information com- 
munication system connectable via a serial bridge 
having portals respectively connected to different 
serial buses and a registration table for registering 
node information, characterized in that said com- 45 
puter program streams enabling the information 
communication system to perform the following op- 
erations; 

registering information of a connected node 
in addition to serial bus designating information in so 
the registration table for each serial bus connected 
to the serial bridge, monitoring bus reset on the se- 
rial bus connected to each portal, when bus reset 
is detected, rewriting, in accordance with newly up- 
dated node information, contents of the registration 55 
table corresponding to a serial bus on which bus 
reset is detected, and updating the registration ta- 
ble, thereby enabling recognizing a change in sys- 
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FIG. 2 
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FIG. 9 



CONFIGURATION ROM OF MINIMUM FORMAT 
8 bits 24 bits 




FIG. 10 



Bus info Block Length 



ROM Length 



CRC 



Bus Info Block 



1001 



Root Directory 



1002 



Node dependent info directory 



03 



Unit directories 



1004 



Root & unit leaves 



1005 



Vendor dependent information 



1006 



40 



EP 1 134 937 A1 



(3 
u. 



o 

O 



oc 

LU 
I— 
CO 

CD 

LU 
OC 

LU 

O 

> 
LU 
Q 

CO 

z> 

CQ 
— I 

< 

oc 

LU 

CO 



LU 
CO 



CO 

a 



m o 

CO LU 



o 

LL 
LL 

e 

o 
o 

CO 



< 

EE 
3 

55 

8 



o 

!*co 

O CD 

cc LU 
O to 



a. 
< 



a 

3 

2 
p 



o 

LL 
CO 

I 

o 
o 
o 



a 

LU 
> 
0C 
LU 
CO 
LU 
DC 



o 

LL 
LL 

T 
O 
O 



O 
LU 
LU 

Q. 

CO 

cr 

LU 
LL. 
CO 

< 



o 

CO 

<: 



CO 
^ ZD 
O CO 

cc lu 
O co 

5o 



£ 

CO 
LU 

OC 



O 
LU 
LU 

a_ 

CO 



O 

LL 

LL 

CVJ 
I 

o 
o 
o 

CVJ 



O 

LL 

LL 
LL 

O 
O 
O 
CO 



41 



EP1 134 937 A1 



FIG. 12 
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FIG. 14 
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FIG. 29 



NODE A1 BRIDGE NODE B1 




59 



EP1 134 937 A1 



CO 

6 

LL 



DC 
LU 

o 

LU 

oc 

CO 

z> 

CD 
— I 
< 

LU 
CO 



o 

3 



CC 
LU 

u_ 

CO 

<c 

CC 

I— 
co 

ZD 

o 
o 

DC 

o 



8 



LU 



□ 

O 
OC 
X 

o 

v> 

X 

2 

CC 

CO 

o 

LU 
X 



X 

3 
co 

X 
LU 

I 

X 
CO 



X 
LU 
O 

o 
o 

x 

ULJ 

o 

ULI 
X 



>- 

3 



o 
< 

CO 

2 



o 



o 

X 



8 



o 

LU 

> 

X 
LU 
CO 
LU 
X 



X 
LU 

<? 



CO 
3 
CD 
LU 
O 
Q 

LU 
Q 

O 



HI 


NUI 


Q 


_J 
LU 






o 






< 


< 


X 


CD 


O 


X 


X 


LU 


LU 


LL. 


U. 


CO 


CO 


2: 


H 


h- 




co 


CO 


3 


3 


O 


O 


~z. 




& 


o 




X 


X 


X 


o 


o 


o 


O 


CO 


CO 


LU 


LU 




o 


s 


< 






< 


(VIA 



X 
LU 
CD 



X 
LU 

O 
LU 
X 

o 

\— 
CO 

O 

1 



> 
X 
LU 
CO 



CO 
3 
CD 

111 

55 

LU 
X 



o 

s 

LL. 

t 

CO 
LU 
X 
CO 



CO 
3 
CO 
LU 



LU 
X 

O 

g 
i— 



CO 
LU 
X 

CO 
3 
CO 
LL. 
O 



2 
X 
LU 
CO 
LU 
X 



LU 



X 
LU 

o 

LU 
X 



LU 



LU 

o 



CO 
3 
CD 



o 

x 



LU 
O 
X 
3 
O 

LU 

o 

x 



5 
O 
LU 



>- 
CO 
3 
CD 



X 
LU 

a 
< 



CO 
3 
CD 



LU 

I 

CD 



Q 

< 
CD 



LU 
— I 
CD 

a 

LU 



< 
X 

o 



o 
o. 



CO 



CO 
3 
CD 

I 

LU 

LU 
X 



LU 
CO 
LU 

=1 

CO 
3 
CD. 



P 

o 



LU O 
CO LU 

Ox 

LU 

X 



o 
o 

CM 



o 

OsJ 



00 

o 

CM 



o 

o 

CM 



o 

CNJ 



00 

cm 
i 

cvi 



O 

cm 



o 

CM 
CM 



00 
CM 
CM 
t 

CM 
CM 



o 

CM 
CM 



O 
CO 
CM 



O 
LL. 
CO 

X 

CO 
CM 



O 
CM 



CM 



60 



EP1 134 937 A1 



CO 
Li. 



(0 

O 



CO 



15 
o 



o 
o 



LJJ 
Q 
O 

z 



CO 
3 
CQ 



61 



EP 1 134 937 A1 



FIG. 32 
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FIG. 33 



N0DEA1 BRIDGE NODE B1 
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FIG. 34 

N0DEA2 BRIDGE NODE B2 
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FIG. 35 
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FIG. 37 

NODE A1 BRIDGE 1 BRIDGE 2 NODE B1 
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FIG. 38 



NODE A2 BRIDGE 1 BRIDGE 2 NODE B2 
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FIG. 40 

NODE A1 BRIDGE NODE B1 
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